[swift-evolution] [Idea] Extending syntax for `extension`

[Xiaodi Wu]

One thing to consider:

Access modifier rules for extensions as they were revised in the Swift 3
evolution process only work if extensions are guaranteed not to be nested,
because they assume private in the outer scope is equal to fileprivate in
the inner scope.

(These rules differ from those for types because extensions are not
first-class entities. For a type, members default to internal but
visibility is limited by that of the containing type. For extensions, since
they are not an entity of their own, the modifier in front of the word
"extension" is merely a shorthand for the default access modifier for
members contained within, the visibility of which are limited by that of
the type being extended.)

Furthermore, IIRC, the rules assume that extensions can never extend a
nested private type, since such a type could never be visible to an
unnested extension.

Should nesting of extensions inside types be permitted, it would
necessitate changes to access modifier rules that did not gain consensus
for review in the Swift 3 timeline.

On Mon, Dec 5, 2016 at 23:34 Braeden Profile via swift-evolution <
swift-evolution at swift.org> wrote:

> No special restriction here.  Like I said, it’s just another way of
> writing a file-level extension within that namespace.  All the functions
> can then be defined as private, public, internal, etc. as necessary.  The
> point would be to define functionality for something within the right
> block.  If I’m writing an entire set of types within MathEvaluator (or
> SelectMode, or whatever I’m writing), I want to be able to keep the whole
> file within MathEvaluator’s scope.  I do, however, wish to write the
> subtypes in terms of “definition here, functionality there” the way
> extensions allow.
>
> I don’t remember a verdict from the `struct MathEvaluator.Number` syntax
> discussion.  Was that shot down, or still a possibility?
>
> On Dec 5, 2016, at 3:04 PM, Saagar Jha <saagar at saagarjha.com> wrote:
>
> How exactly would this work? Would it restrict the extension to only the
> scope it’s defined in?
>
> Saagar Jha
>
>
>
> On Dec 5, 2016, at 1:48 PM, Braeden Profile via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I really enjoy having the ability to write and nesting my code at the
> appropriate indentation level in my file.  Extensions are fabulous, but I
> wonder—solely for readability/style sake, could we allow you to properly
> namespace your extensions?  Though I don’t know the implementation cost of
> this, I think it could be useful to be able to write this:
>
> class MathEvaluator
> {
> struct Number
> {
> let value: Double
> }
>
> struct Operation
> {
> let numbers: (Number, Number)
> let transform: (Double, Double) -> Double
> }
>
> extension Number
> {
> var factors: [Double]
> {
> // Calculate and return the factors
> }
> }
> }
>
> …which would be completely equivalent to:
>
> class MathEvaluator
> {
> struct Number
> {
> let value: Double
> }
>
> struct Operation
> {
> let numbers: (Number, Number)
> let transform: (Double, Double) -> Double
> }
> }
>
> extension MathEvaluator.Number
> {
> var factors: [Double]
> {
> // Calculate and return the factors
> }
> }
>
> This change is in the same ball park as this, proposed a week or two ago:
>
> struct MathEvaluator.Number
> {
> let value: Double
>
> var factors: [Double]
> {
> // Calculate and return the factors
> }
> }
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161206/c6e78b92/attachment.html>