I agree it would be hard. In fact, it would be the most difficult part about it. Like how the API team at Apple will debate for weeks the name of a foundation method.
Another counter point to my theory is that most developers will go for the automatic "private var". So there would definitely be a habitual ritual learning curve. But imagine how much more accurate and descriptive it would be for new folks. And Crustys (like me) can claim a terse semantic victory, although having to relearn some mental autopilot routines. On Fri, Mar 24, 2017 at 9:42 AM Sean Heber <[email protected]> wrote: > This line of thought seems worth some consideration - why require a mental > mapping from the meaning of “public” to what it *really* is when it could > just say what it means? Although I admit that coming up with decent words > or nice phrasings might be harder than it seems. :) > > l8r > Sean > > > > On Mar 24, 2017, at 6:12 AM, Vinnie Hesener via swift-evolution < > [email protected]> wrote: > > > > I like the idea of changing some reserved words. Aren't 'private', > 'friend, 'public', 'internal', etc just metaphors that were built on top of > object encapsulation (another metaphor)? I think we're starting to see the > limits of stretching metaphoric syntax. > > > > Why can't we just start naming access modifiers literally: a location in > the code that they apply to. Examples such as "scope" or > "insidethecurlybraces" or "file" or "module" or "submodule" or "codebase". > Any of these or other synonyms would be much more Swifty in my opinion. > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
