[swift-evolution] [proposal] Union Type
Leonardo Pessoa
me at lmpessoa.com
Tue May 17 18:37:03 CDT 2016
That's exactly my point, Sean.
- Leonardo
On 17 May 2016 at 20:31, Sean Heber <sean at fifthace.com> wrote:
> Cavet: I have not been following this, so probably someone has said this
> somewhere and flaws were pointed out.
>
> I don’t really understand the need for union types when you can have
> multiple methods of the same name that differ only by the type of their
> parameter:
>
> func something(value: A) {}
> func something(value: B) {}
> func something(value: C) {}
>
> Doesn’t this more or less accomplish the same thing without needing a
> switch/if tree or whatever else inside the method to break the types back
> apart again in the method body and without even needing any new mechanism
> in the language at all?
>
> Again, sorry for the (very likely) redundant noise on my part.
>
> l8r
> Sean
>
>
>
> > On May 17, 2016, at 6:09 PM, Leonardo Pessoa via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Jiannan, I agree there is an use for union types, I'm just not really
> fond of the syntax (I'd really prefer something like 'union<...>') and with
> using it for optionals. To enable this syntax for optionals, None would
> have to be a valid type of the language and that would enable one to create
> the following constructions:
> >
> > func something(value: None) -> None { ... }
> >
> > It wouldn't be essentially wrong but unnecessary since nil would be the
> only possible value of the type None. And I don't really see any need to
> change the way optionals are implemented to support unions. And we could
> still have optional unions using either syntax with existing optional
> syntax (which is very clear to me):
> >
> > func something(value: (A | B | C)?) { ... }
> >
> > or
> >
> > func something(value: union<A, B, C>?) { ... }
> >
> > Just as I said before, I don't really think unions are necessary (did
> you mean overloading?) but I don't oppose them. I just don't think we need
> to change the way a feature already works to justify the addition of a new
> feature.
> >
> >
> > - Leonardo
> >
> > On 16 May 2016 at 08:26, Cao Jiannan via swift-evolution <
> swift-evolution at swift.org> wrote:
> > Union is far better then generic enum/protocol solution.
> > * It can extend the original enum and make it powerful.
> >
> > enum ResultDataType {
> > case Music
> > case Video
> > case File
> > }
> >
> > enum FailureType {
> > case HTTP404
> > case HTTP502
> > }
> >
> > enum FailureTypev2 {
> > case HTTP451
> > }
> >
> > typealias Result = (ResultDataType | FailureType | FailureTypev2)
> >
> > * It keeps the code clear and does not need developer to announce
> some unnecessary protocols or enums.
> > like UnionOf3<T,U,V> or ProtocolForABC
> >
> > * It is easy to wrap original value into an union type.
> > let a = A()
> > let union: (A|B|C) = a // Automatically wrap.
> >
> > * Compiler might search their common properties, and methods, then
> mark them as a member of the union type.
> > print(value.someCommonProperty) // Compiler will know
> their common properties automatically.
> >
> >
> > * Compiler know the union type exactly composed with which types,
> better than only know which protocol.
> > func input(value: ProtocolForABC) {
> > if value is A {
> >
> > } else if value is B {
> >
> > } else if value is C {
> >
> > } else {
> > // There are other cases? Compiler doesn't know
> > }
> > }
> >
> > * Original types and union types can have a rational
> relationship between each other.
> > Original type is a sub-type of union types contain it.
> >
> > var fn0: A->Void = {print(v0)}
> > var fn1: (A|B)->Void = {print(v0)}
> >
> > fn0 = fn1 // Original Type and Union Type has a sub-typing
> relationship, OK
> >
> > var fn2: (A|B|C)->Void = {print($0)}
> >
> > fn0 = fn2 // OK
> > fn1 = fn2 // OK
> >
> >
> > * It is also easy to compare with value of original type.
> > union == a // Can be compared, Yes for most cases.
> >
> > * And the most important part, It can replace Optional<T>.
> > let string: String?
> > is same to
> > let string: (String | None) instead of let string:
> Optional<String>
> >
> >
> > I really think the union type is a good supplement for Swift. Make the
> language rational.
> > And the It is also really good for Reactive Programming.
> >
> > - Jiannan
> >
> >> 下面是被转发的邮件：
> >>
> >> 发件人: Haravikk <swift-evolution at haravikk.me>
> >> 主题: 回复： [swift-evolution] Union instead of Optional
> >> 日期: 2016年5月16日 GMT+8 18:35:25
> >> 收件人: Austin Zheng <austinzheng at gmail.com>
> >> 抄送: Cao Jiannan <frogcjn at 163.com>, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org>
> >>
> >>
> >>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> If A, B, and C are not related via protocol or class inheritance, then
> there is almost nothing you can do with value. Otherwise you still need to
> test against the concrete type using a case statement or a if-else ladder.
> >>
> >> I think that a case statement or similar syntax will still be needed,
> and the case names would just be the types themselves. This would work best
> with support for type-narrowing, for example:
> >>
> >> func someMethod(value:(A|B|C)) {
> >> switch (value) {
> >> case .A:
> >> value.someMethodForTypeA()
> >> case .B:
> >> value.someMethodForTypeB()
> >> case .C:
> >> value.someMethodForTypeC()
> >> }
> >> }
> >>
> >> A union should really just be though of as a lightweight, restricted
> form of enum that can be declared in a quick ad-hoc fashion, similar to how
> tuples are a simpler form of struct.
> >>
> >> I’m generally a +1 for the feature, but I’d be interested to hear about
> how well equipped the compiler is for optimising something like this. In
> most cases an Optional covers what I need, and in more complex cases I’d
> probably declare overloads for each type (i.e- someMethod(value:A),
> someMethod(value:B) etc.); unions could make the latter case simpler, but
> will the compiler produce the same code behind the scenes, i.e- by
> isolating what’s unique to each type?
> >
> >
> > _______________________________________________
> > 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/20160517/ec54301c/attachment.html>
More information about the swift-evolution
mailing list