In terms of black and white, approve or don't approve - I agree with Matt,
thumbs down on this one from me too.
For what it's worth while I also use fileprivate a lot I dislike the concept...
I think pairing scope to something physical like a file is weird - but I also
believe it is a symptom of a flaw in the tooling.
If Xcode supported module/framework based development as easily as IDEs like
visual studio then fileprivate would never have been needed and internal scope
would actually serve a purpose. We would have 'internal' types that can live in
their own files but would be invisible to the consumer of the module/framework.
_That_ would be my hope for access modifiers going forward, but unless Xcode is
open sourced I fear that we have to make language compromises like fileprivate
which as essentially a crutch imo.
Ian Keen.
> I would like to separately concur with (most of) Matt's excellent review.He
> identifies what I think the core issues here, which are
> People code in different styles.A scoped keyword is more useful in some
> styles and less useful in others, and this debate is in many ways a proxy war
> about programming style.
> Most of the "solutions" proposed boil down to telling private users to adopt
> a different programming style.Instead we should be making Swift a great
> language for a *wider* diversity of programming styles as it expands to new
> platforms and solves new problems.
> The complexity argument seems weak or even absent.It consists largely of the
> informal observation that 3 keywords are better than 4, which may "feel true"
> but does not have the research behind it of a Goto Considered
> Harmful™.Instead, most of the research on usage and impact are coming from
> those trying to keep it, which does not seem like their burden to meet.
> On March 23, 2017 at 1:22:49 AM, Matt Gallagher via swift-evolution
> (swift-evolution at swift.org) wrote:
>
> > What is your evaluation of the proposal?
> I disagree with this proposal. It removes functionality that I actively use.
>
> This proposal aims to revert SE-0025 without really addressing the aims of
> that proposal, merely dismissing the result as "actively harmful" without
> defining what that means. SE-0159 raises the complaint that "private" is
> syntactically more natural default while "fileprivate" is a more useful
> default. On this point, I agree but the proposal is not about mere renaming.
>
> The other discussion in the proposal is to ask the questions:
>
> 1. is that distinction between private and fileprivate actively used by the
> larger community of Swift developers
>
> 2. if it were used pervasively, would it be worth the cognitive load and
> complexity of keeping two very similar access levels in the language?
>
> Fair questions but despite the proposal claiming "This proposal argues that
> answer to both questions is no", the proposal offers no *arguments* for the
> answers, it merely states a position.
>
> For this reason, I feel the proposal is unreasonably dismissive of the aims
> of SE-0025.
>
> Frankly, both these questions have subjective answers based on how
> programmers tend to design their programs. I personally like to build
> functionality using lots of very tiny types (many just 4 or 5 lines long),
> therefore, I frequently put multiple types in the same file (they're part of
> the same functionality, even if they're not part of the same type). However,
> I want to have actual interfaces and implementation hiding between them
> otherwise there's always the possibility of accidentally abusing the
> interface to each type. An access modifier narrower than the file, like the
> current scoped "private", is the *only* way to achieve this.
>
> Reverting SE-0025 means the only way to have enforced interfaces between
> types is to place them in separate files. This is counterproductive for tiny
> types that form a single conceptual entity. Separate files also requires
> whole-program optimization for optimal performance.
>
> The only conclusion I can make is that programmers in favor of this proposal
> simply don't program this way. However, I find it insulting that this
> proposal is essentially saying: your way of designing and structuring
> programs is wrong; you must use big monolithic types in their own files and
> endure reduced compilation (whole-program optimization) or runtime
> performance (no inlining between files with whole-program off).
>
> I can't help but feel that this proposal is really misdirected frustration.
> Programmers who don't use clusters of tiny types in a single file shouldn't
> care about the existence of a scoped access modifier because it shouldn't
> affect them – they should use file access modifiers and be done. Yet
> apparently, it is file access modifier advocates pushing this proposal.
>
> It really seems like the existence of a scoped access modifier is taking the
> blame for people's frustration that the simpler keyword ("private") is a less
> good default than the clunky keyword ("fileprivate"). I personally agree that
> the behavior or "fileprivate" is probably a better default so I understand
> the desire to give "private" back that meaning again. However, I don't want
> to lose a scoped access modifier because it is *useful* (for reasons of both
> project structure and compilation or runtime performance).
>
> So... thumbs down from me. However, if someone wants to rename fileprivate
> ->private and rename private ->scope (or something) I'd be more supportive.
>
> Regards,
> Matt Gallagher.
>
>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
