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

[Braeden Profile]

No, I personally haven’t found a use case besides aesthetics.  The whole access level situation never even crossed my mind, originally, and they do become terribly confusing in this case.

I would appreciate the resolution of a bug that makes this syntax unnecessarily appealing:

struct A
{
	struct B
	{
		struct C
		{

		}
	}
}

extension A.B.C
{
	var foo: C {  } //error: unidentified type C
	var bar: B.C {  } //error: type B doesn’t have a subtype C
	var faz: A.B.C {  } // fine (yet wordy), given an implementation.
}

> On Dec 6, 2016, at 4:55 PM, Robert Widmann <devteam.codafi at gmail.com> wrote:
> 
> Exactly.  Worrying about implementation cost is secondary (hey, everything in the compiler is an engineering effort!) to the mess this would make of the semantics of (file)private inner aggregates.  
> 
> Considering you yourself cite it being sugar, have you run into a case where this rule can be applied to, say, clean up code in a meaningful way?  The given example, while visually appealing, seems awfully domain-specific. 
> 
> ~Robert Widmann
> 
> 2016/12/06 1:03、Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
> 
>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161207/e6f03d99/attachment.html>