> Le 1 juin 2016 à 02:55, Austin Zheng via swift-evolution
> <[email protected]> a écrit :
>
> Maybe it's overkill. My personal opinion is that breaking the symmetry of the
> language like this (are there any other types of function arguments that
> cannot be passed as either variable values or literals?) is too much a price
> to pay. Your library thinks it's being clever and vends its functions as
> taking anonymous enum flags, and now there are a bunch of things I can't do
> with those functions anymore.
'inout' doesn't accept literal, function-like compiler directive cannot use
variables. So both variables and literals are not always both accepted; not
sure though if it can be used as a precedent for this ad-hoc enum.
Dany
> A regular enum can be declared in one line anyways:
>
> enum ScaleCropMode { case Fit, Fill }
>
> Austin
>
>> On May 31, 2016, at 11:44 PM, Charles Constant <[email protected]>
>> wrote:
>>
>> > It breaks the ability to pass in a variable containing the desired value,
>> > rather than the literal value itself.
>>
>> Maybe that's appropriate? If the caller is not passing in a hardcoded enum
>> case, then that enum is probably general enough that it warrants a normal
>> enum. But there are also situations where the same function is called from
>> several files in the same code-base with different flags. Those are
>> situations where it feels like overkill to clutter up my codebase with
>> separate enums, only used by a single function.
>>
>>
>>
>>
>>
>>> On Tue, May 31, 2016 at 9:24 PM, Austin Zheng via swift-evolution
>>> <[email protected]> wrote:
>>> I admire the desire of this proposal to increase the readability of code.
>>> I'm -1 to the proposal itself, though:
>>>
>>> - It breaks the ability to pass in a variable containing the desired value,
>>> rather than the literal value itself. (Unless you actually want a
>>> not-so-anonymous enum type whose definition happens to live in a function
>>> signature rather than somewhere you'd usually expect a type definition to
>>> live.)
>>> - It breaks the ability to store a reference to the function in a variable
>>> of function type (ditto).
>>> - Almost every time I've wanted to use one of these "anonymous enums" in my
>>> code, I've ended up needing to use that same enum elsewhere. In my
>>> experience, 'lightweight enums' don't end up saving much time compared to a
>>> full-fledged one.
>>>
>>> Like Brent said, I have to say no to any proposal that tries to make enums
>>> synonyms for numerical values. What happens if you rearrange your anonymous
>>> enum cases between library versions? Do you somehow store an opaque
>>> case-to-UInt8 table somewhere for every anonymous enum you define for
>>> resilience? What happens when people start bringing back terrible C
>>> patterns, like doing arithmetic or bitwise ops on the underlying case
>>> values? At least you have to try pretty hard as it is to abuse Swift's
>>> enums.
>>>
>>> Austin
>>>
>>>> On Tue, May 31, 2016 at 8:25 PM, Brent Royal-Gordon via swift-evolution
>>>> <[email protected]> wrote:
>>>> > And the obvious answer is you can have up to 255 of these babies for the
>>>> > anonymous enum type, and be able to pass numerical equivalents UInt8
>>>> > with compile time substitution. That the ad-hoc enumeration is basically
>>>> > a syntactic shorthand for UInt8, with an enforced upper bound compile
>>>> > time check simplifies everything including switch statements.
>>>>
>>>> If I wanted a language like that, I'd be writing C, not Swift.
>>>>
>>>> --
>>>> Brent Royal-Gordon
>>>> Architechies
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
