On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution 
<swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to