[swift-evolution] Ad hoc enums / options

[L Mihalkovic]

> On Jun 7, 2016, at 10:29 PM, Erica Sadun via swift-evolution <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:
>> 
>> 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.
> 
> 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.


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