[swift-evolution] Group "typedef" language feature

[Tony Allevato]

On Mon, Mar 13, 2017 at 4:41 PM Tony Allevato <tony.allevato at gmail.com>
wrote:

> On Mon, Mar 13, 2017 at 4:41 PM Tony Allevato <tony.allevato at gmail.com>
> wrote:
>
> This strikes me as fairly equivalent to "union types", which are on the
> frequently rejected proposals list:
>
>
> (hit Send too soon)
>

(My e-mail client hates me today; apologies for the spam)

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md



>
>
>
>
>
>
> On Mon, Mar 13, 2017 at 4:14 PM Elijah Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I don’t know if this feature has yet existed in any languague, but its
> pretty simple.
>
> Let say you are preparing data for a JSON encoder. Right now, you would
> add to an Dictionary or Array like this one:
>
> let data = [String:Any]();
>
> but what one is really saying is that “Any” is from a number of distinct
> types:
>
> group typedef JSONValueType : String, Double, Int, [String:JSONValueType],
> [JSONValueType], Bool
>
> So from the compiler’s point of view, this group typedef would be just
> like the “Any” type, only it would refuse to compile unless the proper type
> was passed. So the result would be, as an example, that there could be
> created an (almost) fail-safe JSON encoder:
>
> let data = [String:JSONValueType]();
> data[“key] = “value”;
>
> I’m sure this has plenty of uses outside of JSON encoding and would be
> pretty simple to do. One problem that it would solve it the fact that in
> Swift, everything is included by Any, including optionals, ex:
>
> let b : String? = nil;
>
> let a : Any = b; // result is warning: “Expression implicitly coerced
> from String? to Any"
>
> and so there is no way to include value types and objects without also
> including optionals, though this “Any” (like Object and void* in Java/C)
> syntax makes for poorly documented code when the type isn’t really “Any”,
> but a collection of known types.
>
> There already exist protocols, but they are not useful for types that one
> has not defined (like the basic system types), or for mixing particular
> values, structs, and classes.
>
>
You can retroactively extend any type to support a protocol, so that's one
way that you could achieve this. The catch is that you don't want arbitrary
types outside the set that you bless to be able to conform to that
protocol. For that case, I think being able to define a "closed" protocol
would be nice and achieve what you want,



> _______________________________________________
> 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/20170313/a2f2b4bd/attachment.html>