[swift-evolution] Ad hoc enums / options

[L. Mihalkovic]

> On Jun 1, 2016, at 1:06 PM, 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 {

I think it is a very reasonable proposal that does not violate the language.

Enums are nominal types, so what makes them unique is their names. It means that the name CANNOT be RANDOMLY generated... But it does not mean that the name cannot be meaningfully generated... So it is perfectly reasonable for the compiler to behave like a beginer programmer might and go through a naive but predictable heuristic to derive a semantically meaningful unique name:

Public enum enum_Fit_OR_Fill {
    case Fit
    case Fill
}

The prefix may not even be required. There is no chance that the name would wind up colliding with something done manually, and fixing the declaration to be systematically done at the module level would ensure clear visibility. The method signature would also be clean with "operation" exposed as:
    operation: enum_Fit_OR_Fill

To deal with milti site definition, the compiler would simply flag a error/warning, or be silent in the presence of a new annotation:

@strawman_use_synthesised_enum func scaleAndCropImage(....)

This would indicate that we acknowledge taking full responsibility for avoiding name collisions

To be more defensive, there could be a rule stating that these cannot be exported from modules (basically cannot be API). This is nothing more than a simple exercise of syntax sugaring...

Now having said that, if I recall, chris was clear that sugaring in NOT for 3.0


>> 
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/fd02eeff/attachment.html>