Sent from my iPad
> On Jun 1, 2016, at 6:35 AM, Leonardo Pessoa via swift-evolution > <[email protected]> wrote: > > Unions have been discussed earlier in this group and I personally > think this is an issue better solved using function overloading. > Despite this, I see how union types could be implemented (hint: > Optionals) but to use it in code would require you to, at least, test > for the type of the value at hand for the blocks of different code > between types. It feels like trying to bend a static typed language to > work a bit like a dynamic typed and while both have their pros and > cons I don't really think there is any benefit for the programmer and > the readability of the code in bending the type checker like this. Unions are a specialized tool that should be used carefully and precisely. That said, I have been uncovering several use cases where they are *exactly* what is needed. Without them you end up with boilerplate of one kind or another. > > L > > On 1 June 2016 at 08:06, Haravikk via swift-evolution > <[email protected]> wrote: >> I agree the second is much nicer, and a lot clearer on what each of the >> options does; fitImage: true is pretty clear, but fitImage: false is not, >> but the ad-hoc enum is clear on both counts. That said, the questions of >> interoperability are a big issue for ad-hoc enums, as either they’re too >> strict which becomes inconvenient (a .Fit | .Fill working with one method >> but not another) or too relaxed to be safe. Of course, in the latter case >> you’re replacing a Bool, which couldn’t be more relaxed in terms of where it >> accepts values from. >> >> Still, I think in this case it would be better to fully-define an enum, as >> it gives you total control over compatibility and reusability of the type, >> which you can’t really with the ad-hoc form without making it overly >> complex. >> >> The main type of ad-hoc enum I want to see is a union-type like so: >> >> func someMethod(value:(Int | String)) { … } >> >> This would basically be an ad-hoc enum where each case identifies one of the >> possible types, and the value bound as that type. This works however because >> there’s no ambiguity in the meaning; an (Int | String) is the same wherever >> you use it, whereas a general-purpose ad-hoc enum is less clear, as an other >> method might also take .Fit and .Fill values, but these may have a slightly >> different meaning. >> >> So yeah, I like the idea in principle, but I think in practice it has too >> many headaches to overcome for it to be as simple as it first appears =( >> >> On 31 May 2016, at 17:16, Erica Sadun via swift-evolution >> <[email protected]> wrote: >> >> Here's a function signature from some code from today: >> >> func scaleAndCropImage( >> image: UIImage, >> toSize size: CGSize, >> fitImage: Bool = true >> ) -> UIImage { >> >> >> And here's what I want the function signature to actually look like: >> >> func scaleAndCropImage( >> image: UIImage, >> toSize size: CGSize, >> operation: (.Fit | .Fill) = .Fit >> ) -> UIImage { >> >> >> where I don't have to establish a separate enumeration to include ad-hoc >> enumeration-like semantics for the call. A while back, Yong hee Lee >> introduced anonymous enumerations (and the possibility of anonymous option >> flags) but the discussion rather died. >> >> I'm bringing it up again to see whether there is any general interest in >> pursuing this further as I think the second example is more readable, >> appropriate, and Swifty than the first, provides better semantics, and is >> more self documenting. >> >> Thanks for your feedback, >> >> -- Erica >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
