[swift-evolution] struct subtyping

[Jim Kubicek]

I’m a big fan of adding `newtype` behavior to swift, I think being able to add new types that mirror (but are not compatible with) existing types would be powerful and I would get a lot of use out of them. I’m not a fan of adding subtyping to structs, IMHO, the complexity is not worth the power.

Could we accomplish something similar to `newtype` by making the `typealias` declaration more powerful? If we had the ability to extend typealiases it would get us most of the way there. 



> On Mar 21, 2016, at 4:58 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Many languages which adopt the concept of value types don't allow subclassing for those, and so does Swift.
> Inheritance for structs is more complex than inheritance for classes, but the "final" limitation isn't the only possible solution, and Dave Abrahams told me in another thread that changing this rule might be considered in the future — so I'll risk getting taunted by the cool kids who are in favor of eliminating all ancient OOP-ideas ;-) and start a discussion.
> 
> I guess most readers know about the low-level problems that arise when we switch from pointers (always the same size) to value types (size may vary), so I'll start with two possibilities for struct subtyping:
> 
> newtype (see https://www.haskell.org/tutorial/moretypes.html <https://www.haskell.org/tutorial/moretypes.html> — or just read on if you are scared by Haskell ;-)
> 
> When a subtype does not add any stored properties to its superclass (memory layout doesn't change), there is no difference at the level of object code — only the type checker may stop you from using those two types interchangeably.
> Some use cases:
> - In Cocoa, there is no separate class for (file system) paths; instead, there are some additions to NSString. String doesn't have those abilities, and imho methods like "stringByAppendingPathExtension" deserve a separate Path-struct, so that those special methods don't pollute the method list of String (URL is the future, so that example is somewhat out-of date).
> - You could impose incompatibility on numeric types to ensure that your calculations use correct quantities. Although this can be annoying (Float vs. CGFloat), decorating numbers with quantity/unit could eliminate bugs that had really disastrous consequences in the past.
> - Increased comfort for floating-point math:
> struct CustomDouble: Double
> 
> func == (a: CustomDouble, b: CustomDouble) -> Bool {
> 	return abs(a.value - b.value) < 0.01
> }
> (no need to specify tolerance for each comparison)
> 
> Full subtyping
> 
> As long as you don't cross module borders, it wouldn't be that complicated to add inheritance without restrictions.
> imagine you have a "Customer"-type and a "Employee"-type to store personal data (name, address…).
> Those data objects are perfect candidates to be implemented as structs, but they also cry for a "Person"-superclass, so you are forced to either duplicate code, or to implement your objects as reference types.
> 
> In a real proposal, I would include more details on the problems caused by this feature, but I'd like to see some feedback first.
> 
> Best regards,
> Tino
> _______________________________________________
> 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/20160321/f82ca4af/attachment.html>