[swift-evolution] Ad hoc enums / options

[Hooman Mehr]

Good point. 

This is one of my main concerns: Adding too much to the core language makes it harder to learn. 

I think we should focus on eliminating special cases and exceptions in the language and only add simple foundational enabling features that can enable addressing other issues (boilerplate, namespace pollution, etc.) An example of such enabling feature would be property behaviors. It is a pity that it didn’t make it to Swift 3.0. 

There are many accepted proposals that individually make sense, but when you add all of them together it leads to (in my opinion) more complexity in the core language than is really necessary. 

I think what I proposed is a step in limiting the introduced complexity for fully covering the feature if we really have to have this feature. 


> On Jun 4, 2016, at 8:03 AM, LM <laurent.mihalkovic at gmail.com> wrote:
> 
> Anyone thinking about complexity????
> 
> On Jun 4, 2016, at 4:58 PM, Hooman Mehr via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> How about this:
>> 
>> 
>> Going back to Erica’s original example:
>> 
>> func scaleAndCropImage(
>>     image: UIImage,
>>     toSize size: CGSize,
>>     operation: (.Fit | .Fill) = .Fit
>>     ) -> UIImage {
>> 
>> And noting that we are already allowed to declare an enum inside the function, compiler can generate  an enum scoped inside the function named the label of the enum:
>> 
>> func scaleAndCropImage(
>>     image: UIImage,
>>     toSize size: CGSize,
>>     operation: (.Fit | .Fill) = .Fit
>>     ) -> UIImage {
>> 	@_exposed num operation {
>> 	case Fit
>> 	case Fill
>>     }
>> 
>> Then you could declare a var:
>> 
>> var myOperation: scaleAndCropImage.operation = .Fill
>> 
>> Then you can call:
>> 
>> let scaledImage = scaleAndCropImage(image: myImage, toSize: theSize, operation: myOperation)
>> 
>> @_exposed above would be a compiler private annotation for the auto generated enum that will make if visible outside of the function. This way the impact is minimal and such ad hoc enum would be just the same as any other enum. The only big change in the compiler would be the ability to make some declaration inside functions visible to the outside code.
>> 
>>> On Jun 3, 2016, at 5:10 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On Jun 3, 2016, at 6:44 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>> 
>>>> 
>>>>> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> What about the ABI? This sounds expensive to implement.
>>>>> 
>>>>> Consider this set of ad-hoc enum types:
>>>>> 
>>>>> (.a | .b)
>>>>> (.c | .d)
>>>>> 
>>>>> Naive implementation: we'll represent these things as ints, with .a=1, .b=2, .c=1, .d=2.
>>>>> 
>>>>> The naive implementation breaks when a newly-loaded shared library or some library evolution adds this type:
>>>>> 
>>>>> (.a | .b | .c | .d)
>>>>> 
>>>>> In order to provide ABI stability in the face of arbitrary ad-hoc enum types we must ensure that every ad-hoc enum value has a globally unique ABI representation. 
>>>>> 
>>>>> You could constrain ad-hoc enum values to module or class boundaries and prevent creation of types that use values from different places. For example, if Foundation defines (.a | .b) then you can't define your own ad-hoc enum (.a | .b | .c) that is compatible with Foundation's value for .a. Then the implementation could use ordinary symbols. If usage of ad-hoc enums is not constrained then ordinary symbols don't work because there is no universally agreed-upon place where .a is defined.
>>>> 
>>>> In my mind, the ad hoc enum must be tied to a specific function or method signature. In doing so, it has a unique module/selector associated with it, so it's not just .a but rather Foo.funcname.a (assuming no more than one ad hoc enum per function) or Foo.funcname.3.a (assuming its the third parameter of the selector). The conversation has drifted a bit from my request.
>>>> 
>>>> If the enum needs to be used in more situations, it needs to be a proper enum because the semantics are tied to a higher level of visibility.
>>>> 
>>>> I'm striving for enhanced readability in intent (for example, where !x is a poor description of the option other than x, or even when there are >2 options that will never be used elsewhere such as fill, fit, scale) and in expression (choosing self-annotating switch statements over if statements, where its clear what each branch intends to do).
>>>> 
>>>> These enums would be limited to basic hashValue types, and would appear in QuickHelp as annotations of legal values to supply to the argument. My intent is that there never be more than 3-5 enumeration cases used in this anonymous fashion.
>>> 
>>> Are you still insisting that we not be able to declare a variable holding one of these to call the function with later?  If so, what is the justification for placing a burden on callers that the argument must always be a literal?  If not, how do you suggest a variable be declared?
>>> 
>>>> 
>>>> -- E
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160604/a5ce997e/attachment.html>