Copying is a much more nuanced issue than just reference-or-value though. I would also support some good copying protocols in the standard library, but that's additive.
> > On Oct 21, 2016 at 5:11 pm, <Mike Kasianowicz (mailto:[email protected])> wrote: > > > > Just from an outside perspective, the class restriction seems to be there as > a kludge for technical reasons... but that's neither here nor there. > > > It is not so much to enforce a lack of identity - in the struct case, it > would be to enforce copy-by-value semantics. I think the strongest > argument I've got is, say, a serialization or caching framework where you > want to enforce that something is entirely writeable via memory pointer or > copyable. A value-type restriction would get us mostly there, albeit there > would still be ways to break the contract. However, as noted in my > previous email, I see a lot of possibilities for enums too - in that case the > protocol somewhat acts as 'base type' without adding the complexity of a base > type. > > > > I listed some of my examples in my previous email - I could elaborate if it > helps. > > > > On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner <[email protected] > (mailto:[email protected])> wrote: > > > > > > > > > IIRC, the reason we have "class" there is for the optimiser, so it can > > optimise for the protocol being satisfied by a reference-counted type. > > Classes are semantically unique from values because they have identity, > > which is also something a protocol might want to codify. > > > > > > > > There may be some optimisation gains by requiring all conformers to be > > values, but I struggle to think of why you might want to codify that a > > conformer should not have identity. > > > > > > > > Personally I don't really like this asymmetry in the language either, and > > would support changes to make these two elements more explicit. For > > example, a magic "hasIdentity" protocol which is automatically satisfied > > only by classes, and moving the optimisation guides to usage site (e.g. > > when declaring a variable of type MyProto, I could declare it of type > > AnyClass<MyProto> or AnyValue<MyProto> instead, to annotate this specific > > instance as being refcountable or not, without making such optimisation > > hints part of the MyProto definition) > > > > > > > > > > > > > > > > > > - Karl > > > > > > > > > > > > > > > > > > > > > > > > On Oct 21, 2016 at 8:39 am, <Mike Kasianowicz via swift-evolution > > > (mailto:[email protected])> wrote: > > > > > > > > > > > > > > > > > > Currently protocols can have the class constraint: > > > protocol MyProtocol : class {} > > > > > > > > > > > > It would be (a) intuitive and (b) useful to allow such things as: > > > > > > protocol Model : struct {} or protocol Event : enum {} > > > > > > > > > > > > These types of restrictions can help prevent accidental anti-patterns or > > > misuse of APIs. > > > > > > > > > > > > Seems simple and non-controversial... right? > > > > > > > > > > > > [Note: I'd like to see even more heavy-handed protocol restrictions in > > > the future. For example, a protocol describing an enum with a common > > > case, or a struct with no reference members. Great stuff for defensively > > > coding APIs.] > > > > > > > > > > > > _______________________________________________ swift-evolution mailing > > > list [email protected] (mailto:[email protected]) > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > > > > > > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
