[swift-evolution] Proposal: Allow "flat" declaration of nested types

[Rien]

> On 21 Nov 2016, at 11:52, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
> 
> 
>> On 21 Nov 2016, at 08:42, Rien via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Sure you can do that, but I rather write:
>> 
>> struct A.B {…}
>> 
>> than
>> 
>> extension A { struct B {…} }
>> 
>> The first seems much “swiftier” to me.
> 
> Hmm, objectively, it’s not “swiftier” is it, because Swift has had the extension syntax since day 1 and not the dot syntax. What you actually mean is “it looks nicer to me” which is an entirely subjective position, one with which I agree, but I don’t think such arguments should carry much weight. 
> 
> Actually, I’d like to see “it seems more swifty” and equivalent expressions banned from the list. The concept isn’t well enough defined for a serious discussion on the merits of proposed language features. /rant

Agreed, won’t use it anymore.

In swift the dot-notation seems to be the preferred way of expressing hierarchical relationships. Why not allow the use of the dot-notation for inner-type definitions?


>> In fact, now that this “obvious” dot-notation has been pointed out, I wonder why this was not the initial implementation instead of the “extension” keyword.
> 
> The extension keyword is needed in the case where you are extending an existing type to conform to a protocol. Given that we already have (and need) the extension form and we can already do 
> 
> extension A.B { struct C { … } }
> 
> is there an objective justification for adding a redundant way of doing the same thing?

I do not see it as the same thing.
Creating an extension for a protocol is conceptually different from defining an inner type.
It is common to use a different syntax for same-functionaly if the underlying concept is different enough. For example the “if” and “guard” statements.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl