[swift-evolution] Ad hoc enums / options

[Erica Sadun]

On Jun 7, 2016, at 2:49 PM, L Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>> 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.

What appeals to me is scoping the enumeration to the function: Semantic sugar that creates a global

function.parameterName.enum {case ... }

You had suggested using semantic sugar in a different way, did you not? 

-- E

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