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

[Mike Kasianowicz]

Apologies- I did try finding existing documentation or discussion, but all
I found was a stack overflow question asking how to do this.

The way I see it, it would be as simple as implicitly declaring protocols
on a type when a type is declared: class implies ReferenceType, struct
implies ValueType, etc.

In my opinion, this is very similar to the open/sealed argument about class
inheritance.  The API should be able to more strictly communicate the
protocol usage, so it can provide more built-in functionality and better
establish its contract with the consuming code.

I can see some interesting scenarios like-

// API can return success, but relies on dependency injection to
communicate other results
protocol Result : EnumType {
    case success
}

---
// serialization/communication frameworks
protocol Payload : ValueType, OnlyDataType {
}

class MyPayload : Payload { } // error

---

// this type is a collection of types and not a concrete type. it better
indicates intent.
protocol ModuleDefinition : ProtocolType {
    associatedtype View
    associatedtype Model
    // etc
}




On Fri, Oct 21, 2016 at 3:25 AM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> We had similar talks about that topic before. There is a thread somewhere
> on this, but it’s mainly focused on value type semantics.
>
> If I remember correctly we might even discussed to remove the class
> constraint completely from the language and introduce a protocol solution
> to this problem.
>
> There are also some words about the class constraint in the
> GenericsManifesto.md
> <https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#generalized-class-constraints>
>
> Generalized class constraints
>
> The class constraint can currently only be used for defining protocols.
> We could generalize it to associated type and type parameter declarations,
> e.g.,
>
> protocol P {
>  associatedtype A : class
> }
>
> func foo<T : class>(t: T) { }
>
> As part of this, the magical AnyObject protocol could be replaced with an
> existential with a class bound, so that it becomes a typealias:
>
> typealias AnyObject = protocol<class>
>
> See the “Existentials” section, particularly “Generalized existentials”,
> for more information.
>
>
>    -
>
>    Instead of : class we might use : AnyObject as a constraint (or :
>    AnyReference?).
>    -
>
>    Instead of : struct/enum we should have something like : value or even
>    better : AnyValue.
>
> ------------------------------
>
> I believe we should focus on existential types first before fixing this
> gap in Swift. Any<T> might receive the mentioned constraints and could
> create something like this:
>
> typealias AnyObject = Any<class>
> typealias AnyValue = Any<value>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 21. Oktober 2016 um 08:55:40, Xiaodi Wu via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
> What's your use case for distinguishing structs and enums?
> On Fri, Oct 21, 2016 at 1:40 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
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/73961e61/attachment.html>