On Jun 7, 2016, at 2:49 PM, L Mihalkovic <laurent.mihalko...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
