[swift-evolution] [Discussion] What is the future of tuples in Swift?

[Matthew Johnson]

Sent from my iPad

> On Mar 2, 2017, at 6:56 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> newtype feels like a leaky abstraction. Since the new type carries all the protocol conformance and members of the original type, in your example, I could add or divide RecordIds; but if they're database concepts, why would I want to do that?
> 
> If the original type were extended to add members or protocols, would the newtype gain those as well? It must, since types can be split into extensions like that in Swift a priori. So the new type is always effectively a subtype of the original, when what you often want is something that starts off with a smaller subset of its operations instead, and people can extend it in ways you don't expect.
> 
> I'm trying to imagine types where I automatically want *every* operation of its originating type, and having trouble. Even for a unit-like API, there are likely to be arithmetic operations that don't make sense.
> 
> I think a better model would be a general protocol forwarding mechanism for existing type constructs. Then I could define RecordId as a struct, internally it might have an underlying Int representation, but I would explicitly state which protocols I wanted the type to conform to and which of those are forwarded to that underlying Int. This allows us to maintain the semantic importance of protocols and build types in a way that fits existing Swift patterns, and without the magic/danger that newtype could provide.
> 
> The drawback is that if you want only a subset of operations in a protocol, you don't get that easily for free. But you could define your own protocol, retroactively conform the origin type to it *internally*, and then publicly conform the new type and forward... and as far as I can tell, that plugs the abstraction's leaks.

Agree.  I have shared a rough draft of a protocol-based forwarding proposal last year.  I was midway through a second draft when it became clear it was out of scope.  I'm planning to revive it when the time is right.

>> On Thu, Mar 2, 2017 at 4:08 PM Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
>> 2017-03-03 2:13 GMT+03:00 Slava Pestov <spestov at apple.com>:
>> 
>> Does newtype add any new capability that’s not already covered by defining a struct?
>> newtype would forward all members and conformances of the underlying type:
>> 
>> newtype RecordId = Int
>> 
>> let x: RecordId = 5
>> let y = x + 10
>> 
>> extension RecordId {
>>     func load() -> String { … }
>> }
>> 
>> let a = x.load()
>> let b = 42.load()  // error
>> newtypes aim to carry purely semantic information, in this case, that those integers can be used to fetch records from a database. We get additional members only when we are sure that semantic of current instance is appropriate.
>> 
>> As a side effect, it essentially allows to declare one-liner structs with pattern matching. But I agree with Jaden, just adding pattern matching to structs feels more practical. And this feature is more or less orthogonal to the core functionality of newtype.
>> 
>> _______________________________________________
>> 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/20170302/d208d153/attachment.html>