[swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

[Robert Widmann]

> On Jul 31, 2017, at 4:08 PM, Daryle Walker <darylew at mac.com> wrote:
> 
>> On Jul 31, 2017, at 1:45 PM, Robert Widmann <rwidmann at apple.com <mailto:rwidmann at apple.com>> wrote:
>> 
>> As I was saying, I agree with the overall usefulness of newtype-style declarations, but I don’t understand why we need so much syntax for what should just be a pattern in Swift.  Specifically, the idea of automatic delegation of an interface is antithetical to the very reason why Haskell has newtype in the first place.  And in the situations in which I would create an alternate definition of a type, I expect to never inherit the interface of the underlying type because I intend for it to be completely distinct. 
> 
> What would this pattern look like?

Today, a struct wrapping a single stored property will give you both the static and dynamic semantics you’re looking for.  All that’s left is the delegation.

> 
> An alternative inherits nothing by default. You have to explicitly publish members from the underlying type to the current one. And you don’t have to; you can leave members out, or implement trampolines yourself. I wanted something between Go’s taking everything and C++’s taking nothing, more selectable like Haskell. (But I don’t really understand Haskell.)

Haskell’s newtype feature does not provide this kind of delegation.  It’s in the “taking nothing” camp.

> 
>> Additionally, the use of inheritance in alternate definitions seems out of place and the casting section breaks encapsulation.
> 
> Enumerations use similar syntax to specify their raw type. What word, which may have to be new, should be used to serve a similar function as “super” within the main initializer?

Treating an alternate like a protocol is fine - there is prior art in protocols for that.  But having alternatives refine each other doesn’t make much sense to me without a more salient example than the one in the proposal.  

> 
> Isn’t breaking (or at least bending) encapsulation a point of casting? And shorter than calling “rawValue” and/or “init?” a bunch of times?

A cast in C and C++ may be so, but we encourage checked casts where possible and allow you access to the old “a promise to the compiler” kind of casting with unsafeBitCast - and even then we check sizes.  We should try to avoid leaking implementation details like this.

~Robert Widmann

> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/c3063aa0/attachment.html>