Sent from my iPhone > On 22 Jul 2016, at 19:10, Xiaodi Wu <[email protected]> wrote: > >> On Fri, Jul 22, 2016 at 1:04 PM, Goffredo Marocchi <[email protected]> wrote: >> This adds information without being a burden while the current approach >> mixes and matches in a workable but less consistent way. > > It adds no *useful* information. > >> Adopting a protocol is not the same as subclass for, why should it look the >> same syntax wise? > > As Daniel has pointed out, `class A : P { ... }` establishes a relationship > such that `A is P`, regardless of whether P is a protocol or base class.
I do not think it is a fair statement IMHO. A can conform to P and/or be an A. I think the two concepts should stay separate as they are in many languages, but I can accept to be on the losing end of this. > >> 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
