Enums: "Syntactical-Sugar"

— This isn't really about enums, is it?

— What you're talking about can be an issue (or not) out of context. For example:

     let numberOfThings = 5

isn't improved by being explicit about the type:

     let numberOfThings: Int = 5

In fact, it's arguably worsened, since the type is easy to see. OTOH, with something like this:

     let age = complicatedThingIAlreadyCalculated

you have no hope of knowing whether the age is an Int in years, months, days or seconds, or a floating point value of some kind.

In practice, though, so long as you're reading a passage of connected code, and variables are named reasonably and consistently, knowing the type isn't likely to be a problem.

— You should also consider the origins of Swift in reaction to Objective-C. Let's say you have something like this in Swift:

     let myObject = MyObject ()

This falls under the case already mentioned, where it's pretty obvious what the type is. Back in Obj-C-land, we have to type:

     MyObject* myObject = [MyObject new]; // "new" for purposes of illustration only

It got really old really quickly to have to type the class twice in every declaration, when once would have been enough. This tedious duplication of effort in Obj-C was one of the things Swift was designed to avoid — hence the type inference that avoids the explicit type annotation.

— If you're within Xcode, you can always find out the type of a variable you don't know: you can Option-Click on it to find out.

So, yes, some developers have their anxiety levels raised by the lack of explicit typing, but most(?) developers who are used to the language find it a desirable boon for the fingertips. 🙂

It would be nice to have a toggle (as the compiler knows what is going on) to switch either way: to remove all of the type names, or add them in.

Such a toggle wouldn’t be a compiler feature but a feature of Xcode. Personally I think that’d be pretty cool. You could imagine it having four positions:

• Hide all types, to the point where the code won’t compile

• Hide unnecessary types

• Show code as it was written

• Show all types

You could even imagine a refactoring tool that applies one of these policies to a range of code.

If you have specific suggestions, I recommend you put them in an enhancement request against Xcode. Please post your bug number, just for the record.

One awesome example of this idea is the WebKit type profiler. JavaScript is dynamically typed, which can make it hard to understand at times. WebKit can learn the types actually being used by your code and show them to you. If you’re interested, check out this WebKit blog post.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I have to say, this is a very different experience to the usual forums.

Another aspect (as someone with fresh eyes) I thought about with Enumerations was that they're inherently designed to be type-safe, the only way to make a mistake really is to initially declare a member incorrectly. So then, would it not be a great timesaver if any changed made to a member were automatically made on your behalf by the compiler as it's keeping track of everything?

I suppose seasoned coders don't want anything changing without it being from their hands, dot-notation is about the limit perhaps, but I don't see why this would not be welcome?

Thoughts?

Thank you Eskimo for your input, very nice to have official involvement.

I meant toggle in a binary sense, either on or off. Of course you know more about this than I, but it seems like anything can be overcomplicated. I remember when I learned the shortcut for comment marker (yes, I know that too has several versions of itself: multiline comment and documentation comments) and wondered why existing comments had four strokes, but it seems to make sense upon detraction, less things for the compiler to keep track of.

I'm not sure exactly what you're saying. What does "incorrectly" mean? You should be able to rename a case using the Refactor functionality in Xcode, which puts the decision about the scope of the change in your hands. Perhaps that's what you had in mind?

Generally, though, I think it's not really valid to think of enums as syntactic sugar in Swift, since enums have specific kinds of behaviors, unlike C family languages. Swift enums are really a type whose members are themselves pseudo-types, which is more obvious when you think of associated values. You could argue that Swift enums are sugared Swift structs (sort of), but neither is inessential in the way that they are in C.

Or perhaps I just misunderstand what youre saying?

Sorry for the delay.

Suggestion ref: 35018924