Agree that '@_exposed' would be a step back and additional magic. Also, it
is obvious for me that ad-hoc enum should not require using only as literal
on call site - you can have no rights/other reasons to change such function
to extract adhoc to standalone enum to be able to use variable. Also, if we
can declare such ad-hoc enum as type of function parameter - we should be
able to declare such 'simplified' enum type anywhere in our code.
I believe the main question with ad-hoc enum is how such enum will be
represented in type system. I.e. what will be a result of this:
typealias MyType = ((.one|.two)) -> ()
print(MyType)
Will it be
`(adhocenum_7682736) -> ()` or
`(adhocenum_one_two) -> ()` or
`((.one|.two)) -> ()` or other variant?
I believe the only right way to have such ad-hoc enums in Swift is
introduce new kind of type with full rights, so the above typealias will be
printed as `((.one|.two)) -> ()`, so we can declare variable `var e :
(.fill|.fit) = .fill' and have e.dynamicType == "(.fill|.fit)" etc.
But as I understand after the discussion, community don't want/need such
new type and that probably the idea if such new type kind is not really good.
So personally I don't expect any variant of ad-hoc enum will be accepted.
On 07.06.2016 23:49, L Mihalkovic via swift-evolution wrote:
On Jun 7, 2016, at 10:29 PM, Erica Sadun via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jun 4, 2016, at 8:58 AM, Hooman Mehr <hoo...@mac.com
<mailto: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:
varmyOperation: scaleAndCropImage.operation = .Fill
Then you can call:
letscaledImage = 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.
This is my favorite approach (assuming it's technically feasible) as it
preserves the limitation that the enumerations are scoped strictly to the
function but can be referenced outside of it.
* It allows type inference for dropped prefixes because the compiler
can unambiguously match the ad hoc enumeration type to the parameter.
* It introduces the possibility (for Matthew) of assigning a value to a
variable.
* It preserves the notion that an ad-hoc enum makes syntactic and
semantic sense only with respect to its use in a function/method
parameter list.
If an enumeration needs wider semantics, it should be a standalone type,
whether as a nested or not.
Reiterating the reasons for this pitch:
* It streamlines coding, eliminating standalone enumeration types that
are used only once
* It enables you to see all enumeration options at a glance, and can be
reflected in the QuickHelp documentation
* It encourages `switch` coding over `if-then-else` coding so each case
is labeled and self documenting
* It pushes semantics to the call-site in a way that simple Boolean
flags cannot: `operation: .Fit` means more than `shouldFill: false`.
I'd like to know at this point whether Hooman's approach is even
technically feasible, although it's horrible timing the Tuesday before
WWDC to get core team feedback on anything.
There is currently a draft circulating for the removal of @noreturn. If
memory serves, I think there was another annotation recently removed. There
was also the recent change of dynamicType into something like type(of:)..
all these changes have one thing in common: they are streamlining the
language, chasing the magic out and replacing it with the careful
application of a few simple principles. @_exposed would IMVHO be a setback:
* it would introduce a new special annotation
* the annotation would have very little chance of being anything but a
one of, used for a single scenario
Scala went that way years ago, going left right and center, with all sort
of great ideas. In the end, for the past few Scala Days Oderski has been
going on stage explaining why a language with too many clever tricks is in
nobody’s interest.
if and when they decide to focus on small syntactic sugaring enhancements
(akin to javac's Project Coin), then they have an easy way to make it
happen without any magic or special rules.
_______________________________________________
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
