[swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy]

The proposal is not vague. Most questions / misunderstanding is not due to
the proposal itself but due to how these terms are used in other languages.

It does have one unintended conclusion (the potential class injection to
get access). My position on it is not to change it because it's an edge
case that some people want and that makes the design simpler and more
consistent with the terms that it uses (scope).

If my proposal was to disallow adding an inner class to gain access to
outer class, I'd make it explicit. But I am not proposing it, so there
doesn't seem to be a need to include it and cause more confusion (we
already had plenty of emails about the most common use cases). Also, the
core team did not request a clarification on this, so I think it is clear
to anybody who wants to go to that level of detail.

On Mon, Mar 28, 2016 at 7:27 AM Brent Royal-Gordon <brent at architechies.com>
wrote:

> > We already had a very long discussion about all of these topics.
>
> I am not suggesting you change the design. I am suggesting you clarify the
> description of your existing design so that everyone understands what it
> means, because confusion is rampant.
>
> > I'd like to keep "private" to be completely private and not allow class
> injection to gain access, but this is an edge case that could be argued
> either way. I can definitely live with a pure scoped access  for
> consistency and don't want to argue the edge case in a never ending
> discussion.
>
>
> So what you're saying is, you are purposefully writing the proposal
> vaguely so that everyone can assume it says whatever they imagine it says,
> and thus more people will support the proposal?
>
> This is no way to design a programming language.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160328/05c0a02b/attachment.html>