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

Rien Rien at Balancingrock.nl
Mon Nov 21 05:09:14 CST 2016

> 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.


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

More information about the swift-evolution mailing list