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

[Mike Kasianowicz]

I mean essentially what is known as a POD type (plain ol' data) in C++.  A
data payload without clever features.

In this instance, I don't *necessarily* care about whether it's a struct or
class from a 10,000 foot level, so long as it can copy and is composed of
only other value types.  A struct constraint gets us half-way there, but
only incidentally by virtue of value semantics.

In the Cocoa APIs, these are often defined as an NSDictionary with
key-value pairs.  You could subclass NSDictionary and mess with the
consuming API... but it's pretty clear that the consuming API only wants
data and doesn't want you to get clever about it.

(Not to detract from the enum discussion, because I really like where
that's headed re:Tony's email.)

On Fri, Oct 21, 2016 at 12:37 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Fri Oct 21 2016, Mike Kasianowicz <swift-evolution at swift.org> wrote:
>
> > Hooray, I'm not the only one.
> >
> > I agree copying is a much more nuanced issue- but sometimes struct is
> close
> > enough.
> >
> > What I would really like is "this is a data-only type" rather than
> > "struct".
>
> I'm not sure what you mean by “data-only,” but the constraint I want is
> “has value semantics.”
>
> --
> -Dave
>
> _______________________________________________
> 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/702fb604/attachment.html>