Sent from my iPhone
> On Jun 4, 2016, at 9:58 AM, Hooman Mehr <hoo...@mac.com> wrote: > > How about this: > > > Going back to Erica’s original example: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit > ) -> UIImage { > > And noting that we are already allowed to declare an enum inside the > function, compiler can generate an enum scoped inside the function named the > label of the enum: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit > ) -> UIImage { > @_exposed num operation { > case Fit > case Fill > } > > Then you could declare a var: > > var myOperation: scaleAndCropImage.operation = .Fill > > Then you can call: > > let scaledImage = scaleAndCropImage(image: myImage, toSize: theSize, > operation: myOperation) > > @_exposed above would be a compiler private annotation for the auto generated > enum that will make if visible outside of the function. This way the impact > is minimal and such ad hoc enum would be just the same as any other enum. The > only big change in the compiler would be the ability to make some declaration > inside functions visible to the outside code. > The type name would be super verbose, but this does address the basic concerns I have with the original proposal and it is a lot simpler than structural subtyping. >> On Jun 3, 2016, at 5:10 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution