[swift-evolution] Ad hoc enums / options
Matthew Johnson
matthew at anandabits.com
Wed Jun 1 06:49:35 CDT 2016
Sent from my iPad
> On Jun 1, 2016, at 6:35 AM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> 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
> <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
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list