[swift-evolution] Ad hoc enums / options

[Leonardo Pessoa]

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.

L

On 1 June 2016 at 08:06, Haravikk via swift-evolution
<swift-evolution at swift.org> 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
> <swift-evolution at swift.org> 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
> 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
>