[swift-evolution] Ad hoc enums / options

[Vladimir.S]

Agree that '@_exposed' would be a step back and additional magic. Also, it 
is obvious for me that ad-hoc enum should not require using only as literal 
on call site - you can have no rights/other reasons to change such function 
to extract adhoc to standalone enum to be able to use variable. Also, if we 
can declare such ad-hoc enum as type of function parameter - we should be 
able to declare such 'simplified' enum type anywhere in our code.

I believe the main question with ad-hoc enum is how such enum will be 
represented in type system. I.e. what will be a result of this:
typealias MyType = ((.one|.two)) -> ()
print(MyType)

Will it be
`(adhocenum_7682736) -> ()` or
`(adhocenum_one_two) -> ()` or
`((.one|.two)) -> ()` or other variant?

I believe the only right way to have such ad-hoc enums in Swift is 
introduce new kind of type with full rights, so the above typealias will be 
printed as `((.one|.two)) -> ()`, so we can declare variable `var e : 
(.fill|.fit) = .fill' and have e.dynamicType == "(.fill|.fit)" etc.
But as I understand after the discussion, community don't want/need such 
new type and that probably the idea if such new type kind is not really good.
So personally I don't expect any variant of ad-hoc enum will be accepted.


On 07.06.2016 23:49, L Mihalkovic via swift-evolution wrote:
>
>> On Jun 7, 2016, at 10:29 PM, Erica Sadun via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>>> On Jun 4, 2016, at 8:58 AM, Hooman Mehr <hooman at mac.com
>>> <mailto:hooman at mac.com>> 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:
>>>
>>> varmyOperation: scaleAndCropImage.operation = .Fill
>>>
>>> Then you can call:
>>>
>>> letscaledImage = 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.
>>
>> This is my favorite approach (assuming it's technically feasible) as it
>> preserves the limitation that the enumerations are scoped strictly to the
>> function but can be referenced outside of it.
>>
>>   * It allows type inference for dropped prefixes because the compiler
>>     can unambiguously match the ad hoc enumeration type to the parameter.
>>   * It introduces the possibility (for Matthew) of assigning a value to a
>>     variable.
>>   * It preserves the notion that an ad-hoc enum makes syntactic and
>>     semantic sense only with respect to its use in a function/method
>>     parameter list.
>>
>>
>> If an enumeration needs wider semantics, it should be a standalone type,
>> whether as a nested or not.
>>
>> Reiterating the reasons for this pitch:
>>
>>   * It streamlines coding, eliminating standalone enumeration types that
>>     are used only once
>>   * It enables you to see all enumeration options at a glance, and can be
>>     reflected in the QuickHelp documentation
>>   * It encourages `switch` coding over `if-then-else` coding so each case
>>     is labeled and self documenting
>>   * It pushes semantics to the call-site in a way that simple Boolean
>>     flags cannot: `operation: .Fit` means more than `shouldFill: false`.
>>
>> I'd like to know at this point whether Hooman's approach is even
>> technically feasible, although it's horrible timing the Tuesday before
>> WWDC to get core team feedback on anything.
>>
>
> There is currently a draft circulating for the removal of @noreturn. If
> memory serves, I think there was another annotation recently removed. There
> was also the recent change of dynamicType into something like type(of:)..
> all these changes have one thing in common: they are streamlining the
> language, chasing the magic out and replacing it with the careful
> application of a few simple principles. @_exposed would IMVHO be a setback:
>
>   * it would introduce a new special annotation
>   * the annotation would have very little chance of being anything but a
>     one of, used for a single scenario
>
>
> Scala went that way years ago, going left right and center, with all sort
> of great ideas. In the end, for the past few Scala Days Oderski has been
> going on stage explaining why a language with too many clever tricks is in
> nobody’s interest.
>
> if and when they decide to focus on small syntactic sugaring enhancements
> (akin to javac's Project Coin), then they have an easy way to make it
> happen without any magic or special rules.
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>