> On 4 Oct 2017, at 07:16, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Oct 3, 2017, at 10:11 PM, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>>> However I’m still waiting for Dave or Jordan to chime in with the original >>>> justification for the ‘always emit into client’ behavior. IIRC there was a >>>> resilience-related argument too, but I don’t remember what it is now. >>> >>> The only argument I can imagine is the “If it gets inlined, you’re >>> guaranteed to get the version of the symbol you build against”. The >>> concern is that some instances are inlined and some are not, and if the >>> inline and out of line versions diverge then you can have exciting problems. >>> >>> My view on that is that you’ve already lost if you’d done this. If you >>> mark a declaration as fragile (allowing it to be inlined) you’ve >>> specifically guaranteed that you’re not going to be changing the observable >>> semantics of the function. Introducing new performance optimizations is >>> fine of course. >> >> I understand your reasoning here, but note that in Jordan’s proposal, he’s >> adding two new keywords, exhaustive and nonexhaustive. If exhaustive becomes >> @fragile, does nonexhaustive still make sense? > > Independently of how exhaustive is spelled, nonexhaustive doesn’t make sense > to me. It should be the default. Swift doesn’t have keywords to redundantly > specify the default unless there is a specific reason to be able to do that. > > The example often cited is “nonmutating”, but it isn’t there to cover the > default: it is specifically required because setters default to mutating so > it must exist to be change that default.
Happy to see I’m not the only one with this opinion. > -Chris > > _______________________________________________ > 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
