> On 17 Feb 2017, at 00:00, Karl Wagner <[email protected]> wrote:
>
>
>> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I have been thinking a lot about enums and value subtyping lately and
>> decided to write down the ideas I’ve been thinking about. The result is a
>> manifesto-style document that explores a broad landscape of features that
>> could eventually lead to proposals (at the right time, of course).
>>
>> I’m presenting this document to the list now mostly because I am not sure
>> which of these features (if any) might be relevant to ABI stability,
>> particularly with respect to standard library APIs. I do not wish to
>> distract the list from the focus on Swift 4, phase 1. Let’s try not to get
>> distracted by exciting ideas that won’t be in scope until at least phase 2.
>> Feel free to send feedback off list if you’re interested in discussing ideas
>> that may not be relevant to Swift evolution at this time.
>>
>> Because this document covers a pretty broad range of topics it might be a
>> good idea to start a new thread before jumping in to discussion about a
>> specific aspect of it. Please consider doing that if it is relevant before
>> responding directly to this thread.
>>
>> As this is a relatively large document I am only providing a link:
>> https://gist.github.com/anandabits/5b7f8e3836387e893e3a1197a4bf144d
>> <https://gist.github.com/anandabits/5b7f8e3836387e893e3a1197a4bf144d>
>>
>> To whet your appetite, the topics covered include:
>>
>> * Definition of value subtyping
>> * Transitivity of value subtypes
>> * Generic supertype constraints
>> * Axiomatic value subtype relationships
>> * Enums: Value Subtype Relationships by definition
>> * Nominal case types
>> * Nominal unions
>> * Generic enums and Optional
>> * Cases with unbound generic arguments
>> * Structural Unions
>> * Enum subtypes
>> * Inline enum subtypes
>> * Inline generic enum subtypes
>> * Conditional cases (and GADTs)
>> * Inline case types
>> * Nominal cases with inline types
>> * Case type implementation sharing
>> * Shared stored properties
>> * Subenum stored properties
>> * Shared methods and computed properties
>> * User-defined case patterns
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> enum IntOrString: Int | String {
> case Int
> case String
> }
>
> func takesAnonymousUnion(intOrString: Int | String) {}
>
> Haven’t been through it all, just pointing out that “Structural unions” and
> anonymous unions have been suggested and rejected before.
>
> - Karl
(maybe I should elaborate on that, because you do point it out in the document)
What I mean is that the reason this was rejected before was that people should
be using protocols instead, and building semantic contracts. “Int” and “String”
may have a method that looks the same but behaves very differently - the union
provides no guarantees about _behaviour_. Protocols *do* give you guarantees
about behaviour.
Basically, the correct way to write this (today) is:
protocol CommonIntAndStringMethods {
func doSomething()
}
enum IntOrString {
case integer(Int)
case string(String)
}
extension Int: CommonIntAndStringMethods {}
extension String: CommonIntAndStringMethods {}
func myFunc(_ x: IntOrString) {
let val: CommonIntAndStringMethods
if case .integer(let i) = x { val = i }
else if case .string(let s) = x { val = s }
val.doSomething()
}
What you are proposing looks superficially similar, but isn’t. We call
“doSomething” on a single type, with guaranteed same semantics.
- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
