> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> So, if four/five access modifiers are too many, which one is carrying the
> least weight? Which one could be removed to simplify the scheme while
> maintaining the most expressiveness? Which one doesn't fulfill even its own
> stated goals? Well, one of the key goals of `private` was to allow members to
> be encapsulated within an extension, hidden even from the type being extended
> (and vice versa for members defined in the type). It says so in the first
> sentence of SE-0025. As seen above in my discussion with Charles Srstka, even
> supporters of `private` disagree with that motivation to begin with. The
> kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
> private var bar: Int { return 42 }
> }
>
> extension Foo {
> private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly the
> explanation from a core team member on this list, it's unclear if it can be
> made to work without changing how mangling works, which I believe impacts ABI
> and is not trivial at all. Thus, (a) even proponents of new `private`
> disagree on one of two key goals stated for new `private`; (b) that goal was
> never accomplished, and making it work is not trivial; (c) no one even
> complained about it, suggesting that it was a low-yield goal in the first
> place.
Multiple people have already brought up cases in which they are using
‘private’. The repeated mention of another, unrelated use case that was
mentioned in the SE-0025 proposal does not invalidate the real-world use cases
which have been presented. In fact, it rather makes it appear as if the
motivation to remove ‘private’ is based on a strange invocation of the
appeal-to-authority fallacy, rather than an actual improvement to the language.
Many people used to argue against early returns as being tantamount to
littering one’s code with GOTO statements willy-nilly, instead advocating for
assigning to a return variable which would then be returned in the last line of
the function. Swift explicitly rejects this view, offering constructs such as
the guard statement and the error-handling mechanism which specifically
encourage early returns. However, I don’t see people using the non-acceptance
of this particular argument against GOTOs as an argument for eliminating all
structured flow control from the language.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
