-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]> wrote:
> > On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution < > [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] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
