> On 21 Nov 2016, at 11:52, Jeremy Pereira <[email protected]>
> wrote:
>
>
>> On 21 Nov 2016, at 08:42, Rien via swift-evolution
>> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
