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

On 02.08.2017 14:11, Víctor Pimentel Rodríguez via swift-evolution wrote: On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution mailto:swift-evolution@swift.org>> wrote: That would work as well, but it has the downside of forcing a potentially huge number of methods to be im

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

> On Aug 2, 2017, at 10:11 PM, Mike Sanderson wrote: > > It seems that this discussion got sidetracked from the original proposal, > that aimed to provide more visibility about default implementation for > protocols, to the merits of writing functionality for classes and structs in > same-fil

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

It seems that this discussion got sidetracked from the original proposal, that aimed to provide more visibility about default implementation for protocols, to the merits of writing functionality for classes and structs in same-file extensions. 1. `default` for Protocols First, the issue the origi

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

I have always found it curious that extensions cannot be named. Since same-file extension are considered to be superior to comments as a way of separating concerns, wouldn’t it make sense to allow naming of extensions? Extension names could possibly be included in symbols for entities in the ext

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

I disagree about the back-conversion being different. I would've just as easily made a property in CasualAnswer that returns a Bool. The fact that its implemented as an extension of Bool is purely cosmetic and avoids namespace clutter. Also, it doesn't make sense to add semantics to the groupin

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

i would have written it like this < https://gist.github.com/kelvin13/ba42b620f80ee94fbb0d0841056aac97> On Wed, Aug 2, 2017 at 12:34 PM, Gor Gyolchanyan < gor.f.gyolchan...@icloud.com> wrote: > > On Aug 2, 2017, at 7:31 PM, Tino Heth <2...@gmx.de> wrote: > > > Consider these two alternative ways o

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

> On Aug 2, 2017, at 7:31 PM, Tino Heth <2...@gmx.de> wrote: > > >> Consider these two alternative ways of writing the same code: >> https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa >> > Great example —

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

> Consider these two alternative ways of writing the same code: > https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa > Great example — the first is better. But not because of extensions: // MARK: - String

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

Consider these two alternative ways of writing the same code: https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa > On Aug 2, 2017, at 6:57 PM, Taylor Swift wrote: > > I don’t understand how extensions he

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

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 def

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

> On Aug 2, 2017, at 6:49 PM, Rock Yang wrote: > > I found maybe it's unable to provide implementation in protocol declaration > which has associatedtype. > > Here is Sequence, which has Subsequence as associatedtype. AnySequence is > inferred if no custom Subsequence is declared. > > extens

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

> On Aug 2, 2017, at 6:18 PM, Tino Heth <2...@gmx.de> wrote: > > Hi Gor, > > [I'll continue to answer below, but that wont help you with your proposal…] > > The question is wether this > protocol Equatable { > > static func == (_ some: Self, _ other: Self) -> Bool > > default stat

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

> On Aug 2, 2017, at 6:15 PM, Taylor Swift 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 > o

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

Hi Gor, [I'll continue to answer below, but that wont help you with your proposal…] The question is wether this protocol Equatable { static func == (_ some: Self, _ other: Self) -> Bool default static func != (_ some: Self, _ other: Self) -> Bool } extension Equatable {

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

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” t

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

> On Aug 2, 2017, at 5:35 PM, Gor Gyolchanyan via swift-evolution > wrote: > >> >> On Aug 2, 2017, at 5:30 PM, Xiaodi Wu > > wrote: >> >> Besides the comments below on consensus about how to deal with the >> documentation aspect, I should point out that your examp

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

> On Aug 2, 2017, at 5:30 PM, Xiaodi Wu wrote: > > Besides the comments below on consensus about how to deal with the > documentation aspect, I should point out that your example is incorrect. != > is not a protocol requirement of Equatable with a default implementation, but > a protocol exte

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

Besides the comments below on consensus about how to deal with the documentation aspect, I should point out that your example is incorrect. != is not a protocol requirement of Equatable with a default implementation, but a protocol extension method that cannot be overridden which is *not* a protoco

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

> On Aug 2, 2017, at 3:33 PM, Tino Heth <2...@gmx.de> wrote: > > >> The same-file mentality comes from Swift 3, which introduced fileprivate >> (which, since Swift 4, got merged into private within a single file scope). >> With that feature, implementors don't have to choose between access >>

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

> The same-file mentality comes from Swift 3, which introduced fileprivate > (which, since Swift 4, got merged into private within a single file scope). > With that feature, implementors don't have to choose between access > protection and code locality and can get both. You weren't here when t

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

> On Aug 2, 2017, at 2:20 PM, Víctor Pimentel Rodríguez > wrote: > > On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> and if you have a huge entity, it doesn't get better just because you split >> it and hide its complexity. >

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

On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution < swift-evolution@swift.org> wrote: > > and if you have a huge entity, it doesn't get better just because you > split it and hide its complexity. > > > Splitting and hiding complexity is by far the only reasonable way of > dealing

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

On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution < swift-evolution@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

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

> On Aug 2, 2017, at 1:26 PM, Tino Heth <2...@gmx.de> 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

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

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

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

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. Also, please include the original message for ref

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

The problem is real, but afaics, there is some consensus that the best solution is to allow default implementations inside the protocol declaration: Less typing, no new keywords, easy to understand. - Tino ___ swift-evolution mailing list swift-evoluti

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

Good day, swift community! This time, I'd like to bring your attention to an everyday problem which, I'm sure, you've all dealt with at some point. Motivation Many protocols have a lot of default-implemented requirements so that they can be customized, which would otherwise be impossible to do.