> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
