This adds information without being a burden while the current approach mixes and matches in a workable but less consistent way. Adopting a protocol is not the same as subclass for, why should it look the same syntax wise?
Sent from my iPhone > On 22 Jul 2016, at 19:00, Xiaodi Wu <[email protected]> wrote: > >> On Fri, Jul 22, 2016 at 12:42 PM, Leonardo Pessoa via swift-evolution >> <[email protected]> wrote: >> It would still cause confusion if you were only to conform to a single >> protocol (P in "class A : P" is a class or a protocol?). This can be >> solved in code but I don't think it is necessary. > > The point made earlier is salient: if you know what P is, no clarification is > necessary; on the other hand, if you don't know anything else about P, > knowing whether P is a class or protocol is essentially useless even if > you're a reader. What could you possibly do with this information? > >> L >> >> >> On 22 July 2016 at 14:08, Goffredo Marocchi via swift-evolution >> <[email protected]> wrote: >> > I think that the current approach marks a regression in declarative >> > expressiveness as the notion of extending a class over implementing a >> > protocol is blurred while the concepts are IMHO not the same (the latter is >> > about behaviour conformance not a is a relationship): >> > >> > Class/struct B : Class/struct A <Protocol1 & Protocol2> >> > >> > >> > would be a clear and concise way to express it that would not be confused >> > even at a quick glance. >> > >> > Sent from my iPhone >> > >> > On 22 Jul 2016, at 14:47, Charlie Monroe via swift-evolution >> > <[email protected]> wrote: >> > >> > I agree that this is an issue. Mostly nowadays when more and more classes >> > in >> > Swift do not have a superclass - it simply looks weird: >> > >> > class MyClass: DataSource >> > >> > One doesn't know whether "DataSource" is a class, protocol, etc. >> > Nevertheless, I do not feel that :: is the answer. I really liked, how ObjC >> > did it (which isn't possible with the generics now - is it?), but what >> > about >> > something like this? >> > >> > class BaseClass [SomeDelegate, OtherDelegate, ProtocolX] >> > class MyClass: BaseClass [SomeDelegate, OtherDelegate, ProtocolX] >> > extension MyClass [OtherProtocol] >> > >> > >> > On Jul 22, 2016, at 3:14 PM, Vladimir.S via swift-evolution >> > <[email protected]> wrote: >> > >> > >> > I remember that this was discussed, but can't find any decision regarding >> > this.. So, as a last chance, don't we want in Swift 3.0, as big source >> > breaking change, separate class inheritance and protocol conformance in >> > syntax? >> > >> > >> > Sorry if there was a decision about this suggestions. Please let know in >> > this case. >> > >> > >> > I.e. when I see the following I can't understand if the class inherits from >> > base class and conforms to protocols or just conforms to two protocols: >> > >> > >> > class MyClass : First, Second, Third { >> > >> > } >> > >> > >> > We don't have a rule to name protocols with 'Protocol'/other suffix/prefix, >> > or classes with 'T'/'C' prefix or something like this, so I believe to >> > improve the clarity of code we should separate in syntax inheritance and >> > conformance. >> > >> > >> > As I understand we should discuss changes in these areas: >> > >> > >> > 1. class inheritance : >> > >> > class Child: BaseClass >> > >> > >> > 2. class conformance : >> > >> > class Child: SomeProtocol1, SomeProtocol2 >> > >> > >> > 3. class inheritance + conformance : >> > >> > class Child: BaseClass, SomeProtocol1, SomeProtocol2 >> > >> > >> > 4. protocol conformance for structs: >> > >> > struct Struct: SomeProtocol1, SomeProtocol2 >> > >> > >> > 5. protocol inheritance: >> > >> > protocol Child: BaseProtocol1, BaseProtocol2 >> > >> > >> > >> > My suggestions: >> > >> > >> > I) separate inheritance with double colon : >> > >> > >> > 1. class inheritance : >> > >> > class Child:: BaseClass >> > >> > >> > 2. class conformance : >> > >> > class Child: SomeProtocol1, SomeProtocol2 >> > >> > >> > 3. class inheritance + conformance : >> > >> > class Child:: BaseClass : SomeProtocol1, SomeProtocol2 >> > >> > >> > 4. protocol conformance for structs: >> > >> > struct Struct: SomeProtocol1, SomeProtocol2 >> > >> > >> > 5. protocol inheritance: >> > >> > protocol Child:: BaseProtocol1, BaseProtocol2 >> > >> > >> > >> > II) in class definition use parenthesis to separate inheritance and >> > conformance : >> > >> > >> > 1. class inheritance : >> > >> > class Child: BaseClass >> > >> > >> > 2. class conformance : >> > >> > class Child: (SomeProtocol1, SomeProtocol2) >> > >> > >> > 3. class inheritance + conformance : >> > >> > class Child: BaseClass (SomeProtocol1, SomeProtocol2) >> > >> > >> > 4. protocol conformance for structs: >> > >> > struct Struct: SomeProtocol1, SomeProtocol2 >> > >> > or >> > >> > struct Struct: (SomeProtocol1, SomeProtocol2) >> > >> > should be discussed >> > >> > >> > 5. protocol inheritance: >> > >> > protocol Child: BaseProtocol1, BaseProtocol2 >> > >> > >> > >> > III) special word like 'conforms' >> > >> > >> > 1. class inheritance : >> > >> > class Child: BaseClass >> > >> > >> > 2. class conformance : >> > >> > class Child: conforms SomeProtocol1, SomeProtocol2 >> > >> > or >> > >> > class Child conforms SomeProtocol1, SomeProtocol2 >> > >> > >> > 3. class inheritance + conformance : >> > >> > class Child: BaseClass conforms SomeProtocol1, SomeProtocol2 >> > >> > >> > 4. protocol conformance for structs: >> > >> > struct Struct: conforms SomeProtocol1, SomeProtocol2 >> > >> > or >> > >> > struct Struct conforms SomeProtocol1, SomeProtocol2 >> > >> > >> > 5. protocol inheritance: >> > >> > protocol Child: BaseProtocol1, BaseProtocol2 >> > >> > >> > >> > Thoughts? >> > >> > _______________________________________________ >> > >> > swift-evolution mailing list >> > >> > [email protected] >> > >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
