Oops. I have wanted this feature and I have created `name` methods for 
non-String enums numerous times (whether I had to or not, I guess). If there is 
a formal proposal for this, I could not find it. I am obviously not familiar 
with the entire proposal but this is a feature that I have wanted almost from 
the first day I started using Swift.

I would prefer a `name`method for enums and not overload `description`.

A standard way of accessing the unique names of enum values would be compatible 
with a future variant of `enum` that would allow non-unique rawValue should 
Swift ever support that feature of C/C++ enums. (hint) It would become 
requirement for these enums, I think.

Accessing the names of enum values is extremely useful for diagnostics and 
quick and dirty UI e.g. playgrounds. 

> On Jun 1, 2016, at 3:07 PM, Paul Cantrell <[email protected]> wrote:
> 
> 
>> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> This is the case I was thinking of where the module name comes into play. 
>>> Drop those enums into a framework, and you’ll get 
>>> "landed(MyFramework.CoinSide.heads)". Ugh!
>> 
>> This seems to be more of namespace “import” issue than a problem with enums 
>> specifically. Declaring enums within another entity is a useful. I take 
>> advantage of qualified naming to make short, possibly non-unique enum names.
> 
> Yes, in _code_ fully qualified names are useful.
> 
> This thread is the need for unqualified names in _strings_ — for passing to 
> external systems, logging, etc.
> 
> The problematic behavior I was pointing out is that enums get converted to a 
> name-only string when they are at the _top_ level of a data structure, but a 
> fully qualified Module.EnumType.caseName when they're _nested_ inside a 
> collection or another enum. AFAIK, there's no way to override this behavior 
> without manually coding a case statement to map enum values to strings. This 
> proposal would solve that.
> 
> Cheers, P
> 
> 

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to