[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Cheyo Jimenez]

On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution <swift-evolution at swift.org> wrote:

>> On 21 Dec 2017, at 03:32, John McCall wrote:
>> 
>>>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote:
>>>> 
>>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote:
>>>> 
>>>>    • What is your evaluation of the proposal?
>>> 
>>> I am pleased with the broad strokes of this design. I have quibbles with three areas:
>>> 
>>> 1. The `@exhaustive` attribute may be confusing because the term doesn't suggest versioning. My best alternative suggestion is `@frozen`, which matches existing programming terminology: something that has been frozen will not be changed in the future.
>> 
>> I rather like @frozen.  We could use that across language features, so that we don't end up with a keyword per kind of declaration.
> 
> Could this also be used on functions to make them inlinable?
> i.e. The body of the function has been frozen.
> 
> ```
> @frozen
> public func a()
> 
> @available(*, frozen)
> public func b()
> 
> @available(swift, introduced: 4.1, frozen: 5.0)
> public func c()
> 
> ```

My understanding is that frozen / exhaustible is guaranteed by the compiler while inlineable is more of a strong suggestion to the compiler. It would be confusing to use the same word for both. 
> 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md>
> 
> -- Ben
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution