Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

2016-06-22 Thread Antoine Cœur via swift-evolution
> > * What is your evaluation of the proposal? > -1, we are introducing confusion between WHAT is returned and IF it returns > * Is the problem being addressed significant enough to warrant a > change to Swift? > the assumption that the attribute was superfluous was wrong, for

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

2018-01-09 Thread Antoine Cœur via swift-evolution
I read: Ma.allValues.count // returns 8 But that sounds like all values will need to be computed in order to get the count, so some people will be tempted to write: Ma.lazy.allValues.count // returns 8 To avoid that, it may be nicer to make enum `Ma` behaves like a collection directly, so

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

2018-01-09 Thread Antoine Cœur via swift-evolution
And what about, as an alternative: case (_, #unknown): … matches any int and any unknown enum case ... case _: … matches anything ... Then it clearly goes the "pattern matching" way. Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution < swift-evolution@swift.org> a écrit : > On

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

2018-01-09 Thread Antoine Cœur via swift-evolution
I'm not in favor to distinguish #unknown and #known, as it may lead to surprises, like something that previously was unknown becomes known on a newer iOS version for instance. And version-dependant code is clearer if solely handled by the `@available()` syntax. I like the new pattern matching