Enum cases as protocol witnesses

According the the reply above, the function behavior has already been deprecated.

And enum cases dot syntax is the shorthand behavior, it has nothing to do with static var stuff. I'm not sure what you mean.

I think we do want enum cases to work more like functions (see SE-0155). For example - it recently gained the ability to have default arguments. We also want to add more functionality, such as overloading on type, variadic arguments and more... it’s just pending implementation work.

3 Likes

I suppose by "we" a lot of programmers are excluded, including me.

There seems to be a tendency in this forum that want to add more syntactic sugar to the language. People just don't realize other tools could solve this, e.g. code generating tool based on SwiftSyntax.

Do you really think adding these stuff would make more people happy? It just make some language enthusiasts ( I used to be) happy, while make all other programmers confuse. A lot of programmers never visit this site (including my colleagues). While I try to explain some of these threads to them, they are as same confused as me: what's the real benefits of these proposals?

1 Like

I’m sorry, I didn’t mean to imply I am speaking on behalf of the community. I’m just saying that enum case constructors already behave like functions (and more so after SE-0155) - some features are missing but I think it’s merely a matter of doing the implementation work.

I understand your concern about sugar, but personally I don’t think this is one of those “sugar” proposals that make code hard to read or understand. Even though cases are not written as var/funcs, they do behave like one in the language and so it’s not unreasonable to think of them like that.

2 Likes

Relax, I'm just stating the fact that a lot of proposals are actually supported by a small group of people with specific needs.

I can read and understand this proposal. But in order to make more people to feel comfortable to use swift, it seems to me that restricting the number of syntactic sugars is a must. While you could explain to me that this is reasonable, I have to explain to my colleagues that this is reasonable, and they will just think how complicated swift is.

Back to the original point, can't we write sound code without this syntactic sugar? I'll leave this open question for you to consider.

2 Likes

This proposal isn't adding sugar. It's taking two things that already exist in the language and allowing one to apply to the other.

One can already define protocols.
One can already define enum cases.

No new syntax is being added.

10 Likes

Why specifically do you see this as syntactic sugar? What code would be made worse by this proposal?

No methods are automatically generated to meet the protocol conformances? I don't think so.

Even the author says this is syntactic sugar.

And yet I don’t think your definition matches theirs. Thus my questions.

He uses the word in quotes because it's not sugar in the usual meaning of the term. No new syntax is being allowed to enable this feature. This pitch is a lot closer to auto-synthesis, though I'm not sure that case constructors aren't already synthesized. Either way, this pitch is simply requesting that these constructors be considered when matching protocol requirements.

1 Like

So the discussion is moved to whether this is a syntactic sugar? It's meaningless.

Why should we be forced to use 3rd party tools to solve something that the language can naturally provide? It‘s more a mental burden to learn and rely on such tools that generate boilerplate code that we don‘t want to write. Similar we could have decided against property wrappers because they just templates for code synthesis to reduce boilerplate build into the language. I personally don‘t buy the argument you are trying to make, no offence, but the current pitch provides a natural fix for a hole in the language, even though enum cases taking the static namespace is an implementation detail of the language.

4 Likes

Then theoretically this 'workaround' might be valid?

protocol P { 
  static func foo() -> Self 
}
enum E: P {
  case foo(Void = ())
}

At least I get the impression from this part of the mini-manifesto:


I'm not saying that case foo() is meaningful, but if the above workaround works through the combination of the quoted functionality (if accepted and implemented) + this pitch, why not relax the enum the enum case rules a little and allow it!? However this really depends if there is a real need from the community to allow exactly this protocol requirement satisfaction. Personally I'm neutral on this particular example. Even though the workaround is too clever, it would do the trick if it's really necessary for someone.

I suspect you really aren't understanding this pitch.

  1. The compiler already has machinery for matching up a type's methods and properties to protocol requirements.
  2. Enum cases are already given synthesized constructors.
  3. Enums can already conform to protocols.

This pitch is proposing that (1) be extended to look at (2) in order to verify (3).

Absolutely no new syntax or user code will be changed by this proposal. An existing feature is being extended to work in more cases.

9 Likes

I wish the discussion would focus less on what is possible, and more on what actually makes sense - I‘m still waiting for a convincing use case that justifies the added complexity.

5 Likes

This refers to the implementation side of the compiler I think.

This means we could expose new functionality (in this case automatic conformance) based on compiler's existing internal implementation. A enum with non manually written methods could conform to a protocol. The compiler do the conformance stuff for the user, otherwise the user has to write the code himself. Is this not a syntactic sugar?

So whatever you like to call it, there is extra complexity added.

I don't believe that auto-synthesis is considered to be sugar. It's purely a convenience. And, as I wrote, the compiler already does all this stuff, except that it doesn't consider the already auto-synthesized case constructors.

Seems like you're just against change. It's not a helpful attitude when evaluating a pitch or proposal.

4 Likes

Then we have different definitions on what's syntactic sugar. That's has nothing to do with the point I want to make.

Please don't judge me. I'm against unnecessary additive change. We can still write sound code without these things. What I really want are core features that are still missing: atomic properties, better generics interface, async/await etc. Other stuff are really optional, and should be considered carefully whether the extra complexity is needed.

I wouldn't mind if you could bring up reasonable code examples to back up this and solve issues this proposal otherwise would solve? :slight_smile: (I'm happy to change my mind, there is still chance for that.)