Sent from my iPad
> On Jun 1, 2016, at 1:55 AM, Austin Zheng via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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.
+1. Total non-starter to allow functions that are pretty much broken by
design.
>
> 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 <char...@charlesism.com>
>> 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
>>> <swift-evolution@swift.org> 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
>>>> <swift-evolution@swift.org> 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
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
