[swift-evolution] Tuples as NominalTypes
T.J. Usiyan
griotspeak at gmail.com
Fri Sep 16 10:03:06 CDT 2016
Hello Muhammad,
I am not exactly sure what you are after with this or your previous post
about tuples. Tuples are 'type safe' for any definition of 'type safety'
that I can summon. Switching over tuples to restructure them is, in my
opinion, a main source of the type safety provided in tuples. I do hope
that, along with conditional conformance and the ability to add extensions
with self same types, we get the ability to define extensions on tuples.
These features would allow us more convenience when dealing with tuples and
might possibly ease the woes that you are presenting.
TJ
On Fri, Sep 16, 2016 at 4:05 PM, Muhammad Tahir Vali via swift-evolution <
swift-evolution at swift.org> wrote:
> Type safety would make tuples far more powerful than their current
> limitations. Structs are usually used for slightly more complex objects
> compared to tuples and usually, you need them longer in memory. Tuples are
> just for quick manipulation. Since you are interested in just the content
> inside, you should be able to manipulate it quickly. Concrete examples
> would be destructing JSON or manipulating any list. That manipulation
> itself shouldn't be something used with Switch statements or require
> multiple if let statements.
>
> I'm actually not a fan of the C#'s implementation of tuples. Mainly
> because they don't use optionals and the tuple implementation isn't very
> clean
>
> var aTuple = Tuple.Create ("foo","bar",111)
>
> The main problem is that Swift's tuples functionalities are very limited
> to be able to use them.
>
> --
> Best Regards,
>
> Muhammad T. Vali
>
> _______________________________________________
> 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/20160916/4b631f51/attachment.html>
More information about the swift-evolution
mailing list