[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Vinnie Hesener]

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 <sean at fifthace.com> 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 <
> swift-evolution at swift.org> 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
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/704b63c0/attachment.html>