I agree with Ilya that "external" is too easy to confuse with "public", especially given the specifier "extern" in C. Additionally, we think we can get away with renaming "private" because most current uses of "private" (file-scoped) declarations are within the same (brace-bound) scope anyway; "internal" could potentially cause a lot more churn. And as Andrey pointed out, we'd be at odds with C#, the only other language that uses "internal" as an access specifier today.
Jordan > On Mar 29, 2016, at 7:03 , Ilya Belenkiy via swift-evolution > <[email protected]> wrote: > > -1, "external" can be also understood as "exported" or public. I think that > the names in the updated proposal are the clearest. Also, I think that at > this point we need to stop trying to come up with more names. I don't think > that we will ever reach a point where everybody is happy with the names. The > ones that we have now seems to be a good compromise that is in line with > other Swift keywords. > On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> public (unchanged) >>> external (module access) >>> internal (file access) >>> private (scoped access) >> >> >> This seems logical and something I could live with, but how is it better >> than moduleprivate and fileprivate? Also, internal has contradictory prior >> art in C# and Swift 2 (not that it stops us). >> >> And I see the length of moduleprivate and fileprivate as a feature, and >> external/internal lacks it. > > > It is better than moduleprivate and fileprivate in that it is a single word > which is easier to to read and there is less typing. Less typing even with > autocomplete is a benefit. Once you know its meaning, that both are relative > to file access, you won’t have to look it up. Also, just noticed this, when I > type multiword keywords in an email program or chat program autocorrect butts > in. This is of practical value because much work is done in chat and email > programs. > > Simpler is better if it sufficiently conveys the meaning and it does in this > case. The expectation with most keywords are that they be single words, > especially ones that are used the most. > > There is a nice symmetry to internal/external and public/private. > > If external/internal refer to the file, then we don’t need the multiword > descriptive versions. Also, if we decide later that scoping to namespaces is > desired these same already reserved keywords give us more flexibility than > the more specific keywords would allow. Internal/external could refer to the > namespace scope rather than the file scope if it is inside a namespace (this > is beyond the scope of the proposal but trying to think ahead). By not > explicitly stating the scope you gain flexibility > > - Paul > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
