[swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Mike Kasianowicz]

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 <razielim at gmail.com> 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
> <swift-evolution at swift.org>> 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 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/20161021/d5f178ff/attachment.html>