Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Nov 1, 2017, at 9:16 AM, Ben Cohen via swift-dev > wrote: >> On Oct 31, 2017, at 10:11 PM, Chris Lattner via swift-dev >> wrote: >> On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev >> wrote: >>> [Replying to the thread as a whole] >>> >>> There have been a bunch of suggestions

Re: [swift-dev] What can you change in a non-exhaustive enum?

The nice thing about this setup is that it degrades nicely for the 1000-case enum. You have a static check in the compiler for if theNumberOfKnownEnumCases >= SOME_REASONABLE_MAX (or — in the future — as complicated a decision as you want given the number of total cases and the number of cases y

Re: [swift-dev] What can you change in a non-exhaustive enum?

I like Joe’s idea here, with the extension that the client should have just one of these arrays that contains all the symbols that it knows about at the time it was compiled: I.e. in the client: static myKnownOpaqueEnumCases = [MyOpaqueEnum.intCase, MyOpaqueEnum.middleCase, MyOpaqueEnum.string

Re: [swift-dev] What can you change in a non-exhaustive enum?

I think that you are going to be better served by making things more explicit for non-exhaustive enums with binary compatibility concerns. I don’t think that there is a solution that salvages an ordering for a jump table while still allowing open enums to change during the same @availability ver

Re: [swift-dev] Advice dealing with SILGen for switch statements w/ multiple binding patterns

Excellent, that was what I needed - some indication that I wasn’t completely off-base and doing something that ought not be done. :-) Thanks! - Greg > On Oct 24, 2016, at 11:17 AM, Joe Groff wrote: > >> >> On Oct 22, 2016, at 10:32 AM, Greg Titus via swift-dev &

[swift-dev] Advice dealing with SILGen for switch statements w/ multiple binding patterns

Hey All, I’m not sure what to try next here, and could use some advice. For some time — off and on as I have time to get back to it — I’ve been working on switch statements with multiple binding patterns, e.g.: enum A { case left(a: T, b: T) case right(a: T, b: T) var foo: T { swit

Re: [swift-dev] Endgame for Swift 3

> On Jul 15, 2016, at 10:35 PM, Patrick Pijnappel via swift-dev > wrote: > > Isn't half of this done, or something? I seem to remember seeing code about > it, and I think there may even be a hidden switch to enable what is there. > > The parsing code seems to be in place, toggled by the flag

Re: [swift-dev] AST – Understanding @lvalue

An lvalue is something that can be assigned to / changed. The terminology comes from assignment statements: in “foo = bar”, “foo” is a left-value (lvalue) and “bar" is a right-value (rvalue). The difference is that the lvalue is a named location that can take on a new value and an rvalue is just

Re: [swift-dev] Role of Brace-Stmt in Swift AST

Hi Toni, What you are seeing is a side-effect of / workaround for the use of top-level executable statements. In general, at the top level of a source file you expect declarations (of types, of functions, etc) and then statements will be inside those declarations (the implementations of free f

Re: [swift-dev] [Discussion] New refcount representation

> On Mar 16, 2016, at 1:42 PM, Brent Royal-Gordon via swift-dev > wrote: > > This is damned clever. Yes, I agree! >> The MSB bit also becomes set if you increment or decrement a retain count >> too far. That means we can implement the RR fast path with a single >> conditional branch after t

Re: [swift-dev] Advice on SR-580?

Tim, FWIW, I think that one got incorrectly marked as a starter bug. I don’t think the bug is fixable as written. You are right about the immediate cause, and I think that the only thing we _can_ do is mark it conservatively, because that part of the code isn’t type-checked at all, and probably

Re: [swift-dev] Question about implementation of closure capture lists

> On Dec 9, 2015, at 2:39 PM, Chris Lattner wrote: > >> >> On Dec 9, 2015, at 8:57 AM, Greg Titus via swift-dev >> wrote: >> >> Hi all, >> >> I thought I’d take a look at SR-153 "Bad fix suggestion for changing value >> of ca

[swift-dev] Question about implementation of closure capture lists

Hi all, I thought I’d take a look at SR-153 "Bad fix suggestion for changing value of capture list constants" , and I’d really appreciate it if someone more familiar with the code could check my thoughts, rather than me jumping straight to submitting a pull