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