Sent from my iPad
> On Jun 3, 2016, at 6:44 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution >> <swift-evolution@swift.org> wrote: >> What about the ABI? This sounds expensive to implement. >> >> Consider this set of ad-hoc enum types: >> >> (.a | .b) >> (.c | .d) >> >> Naive implementation: we'll represent these things as ints, with .a=1, .b=2, >> .c=1, .d=2. >> >> The naive implementation breaks when a newly-loaded shared library or some >> library evolution adds this type: >> >> (.a | .b | .c | .d) >> >> In order to provide ABI stability in the face of arbitrary ad-hoc enum types >> we must ensure that every ad-hoc enum value has a globally unique ABI >> representation. >> >> You could constrain ad-hoc enum values to module or class boundaries and >> prevent creation of types that use values from different places. For >> example, if Foundation defines (.a | .b) then you can't define your own >> ad-hoc enum (.a | .b | .c) that is compatible with Foundation's value for >> .a. Then the implementation could use ordinary symbols. If usage of ad-hoc >> enums is not constrained then ordinary symbols don't work because there is >> no universally agreed-upon place where .a is defined. > > In my mind, the ad hoc enum must be tied to a specific function or method > signature. In doing so, it has a unique module/selector associated with it, > so it's not just .a but rather Foo.funcname.a (assuming no more than one ad > hoc enum per function) or Foo.funcname.3.a (assuming its the third parameter > of the selector). The conversation has drifted a bit from my request. > > If the enum needs to be used in more situations, it needs to be a proper enum > because the semantics are tied to a higher level of visibility. > > I'm striving for enhanced readability in intent (for example, where !x is a > poor description of the option other than x, or even when there are >2 > options that will never be used elsewhere such as fill, fit, scale) and in > expression (choosing self-annotating switch statements over if statements, > where its clear what each branch intends to do). > > These enums would be limited to basic hashValue types, and would appear in > QuickHelp as annotations of legal values to supply to the argument. My intent > is that there never be more than 3-5 enumeration cases used in this anonymous > fashion. Are you still insisting that we not be able to declare a variable holding one of these to call the function with later? If so, what is the justification for placing a burden on callers that the argument must always be a literal? If not, how do you suggest a variable be declared? > > -- E > > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
