[swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

[Taylor Swift]

I don’t understand how extensions help with code locality. It’s literally a
matter of *curly braces*. I already glue the extension block to the bottom }
of the protocol block anyway by omitting the empty linebreak.

protocol Protocol
{
    func default_function()
}
extension Protocol
{
    func default_function()
    {
    }
}

as opposed to

protocol Protocol
{
    func default_function()
    {
    }
}

I would very much appreciate not having to retype Protocol and
default_function() over and over. The whole cult-of-same-file-extensions
seems to be people refusing to let go of old C++ habits. Have you noticed
that nowhere else in Swift is there a concept of separating type
declarations from type definitions? That’s because people managed to figure
out that typing the same words over and over again doesn’t actually keep
code neater at all.

On Wed, Aug 2, 2017 at 11:27 AM, Gor Gyolchanyan <
gor.f.gyolchanyan at icloud.com> wrote:

>
> On Aug 2, 2017, at 6:15 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> I agree with this, extensions on types defined in the same file are
> generally silly, and default implementations belong in the protocol body. I
> don’t agree with certain style guides prescription of same-file extensions;
> they should only be used to hide protocol conformances that are
> “unimportant” to the functionality of the type. In practice this means only
> conformances like CustomStringConvertible and CustomDebugStringConvertible
> live in extensions.
>
> If you want to group related methods, use linebreaks and whitespace for
> that. Don’t split up the type braces since that messes up the whole
> one-set-of-braces == one type definition visual rule.
>
> The only time it ever makes sense to extend a non concrete type that you
> own is when adding conditional default implementations. Having to extend a
> bare protocol is the product of a language limitation.
>
>
> Take a look at my replies to Tino Heth about code locality and the rest...
>
> On Wed, Aug 2, 2017 at 6:26 AM, Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> That would work as well, but it has the downside of forcing a potentially
>> huge number of methods to be implemented in a single place, reducing the
>> readability as opposed to packing them into semantically related groups in
>> the form of extensions.
>>
>> I really don't get why people are so obsessed with same-file extensions:
>> They are recommended in style guides, influencers blog about them, and
>> they motivated a ridiculous complex change in the access rights system. Yet
>> I haven't seen any evidence that they offer real benefit.
>> Extensions are great for adding useful helpers to existing types, and
>> still allow you to selectively expose details of your own classes — but
>> most people seem to ignore those options and focus on something can be done
>> better with plain old comments.
>> [sorry for the rant — but I think a critical look at extensions is long
>> overdue: I rarely see someone questioning their role, so basically, we are
>> making important decisions based on pure superstition]
>>
>> A protocol itself is already a vehicle to group related methods, and if
>> you have a huge entity, it doesn't get better just because you split it and
>> hide its complexity.
>>
>> Also, please include the original message for reference purposes.
>>
>> [hopes Discourse will happen soon ;-) ]
>>
>> _______________________________________________
>> 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/20170802/dfd7f63c/attachment.html>