thinking about destructuring: allow `value type name` on declarations

What the heck?

Yes, I know, yuck, this breaks the beautiful annotations type/keyword name syntax followed by all declarations. But I think this has already been broken by destructuring.

What do we gain?

Regularity. The language would be easier to learn and easier to compile.

A little bit of backstory

When destructuring was first introduced, I thought it was really irregular that we wrote value foo and String foo while we wrote value [foo] and value [String foo]. This proposal gracefully solves that problem.

Regularity?

Imagine that you want to destructure a tuple. Here is how you’d do it:

value [v] = [""];

Imagine that we’d like to be explicit about the type:

value [String v] = [""];

Here we can clearly see that v is as much of a destructuring pattern as String v.

We can imagine the destructuring syntax being the following:

• keyword? pattern = rhs

We can imagine the pattern syntax being the following:

• type? identifier
• [pattern+]
• pattern->pattern

is conditions

Whenever the destructuring is done in an is condition, the keyword (is) and all the type must be present. That is, all the following are valid is conditions:

is Foo foo = bar

is [Foo foo] = bar

is Foo foo->Bar bar = baz

is [Foo foo->Bar bar] = baz

While all the following are invalid is conditions:

is foo = bar

[Foo foo] = bar

is Foo foo->bar = baz

is [foo->bar] = baz

exists conditions

Whenever the destructuring is done in an exists condition, the keyword (exists) must be present and each the type may be ommited. That is, all the following are valid exists conditions:

exists Foo foo = bar

exists [Foo foo] = bar

exists foo->Bar bar = baz

exists [foo->bar] = baz

While the following is an invalid exists condition:

Foo foo = bar

for

Whenever the destructuring is done inside a for, the keyword (value) and the each type may be omitted. That is, all the following are valid inside a for:

item in stream

value item in stream

String item in stream

value String item in stream

Integer key->String item  in stream.indexed

value Integer key->item  in stream.indexed

Assignements

Whenever the destructuring is done in a assignment expression, both the keyword and all the types must be omitted. That is, the following are all valid assignment expressions:

foo = bar

[foo, bar] = baz

foo->bar = baz

While the following is an invalid assignment expression:

String foo = bar

Declarations

Whenever the destructuring is done in a declaration, either the keyword (value) must be present, or all the types must be present. In the case the keyword is present, each type may be omitted. That is, the following are all declarations expressions:

value foo = bar

[String foo, String bar] = baz

value [String foo, String bar] = baz

Annotations

Whenever a destructured declaration is annotated with some annotations, it’s the equivalent of each destructured value being annotated with that annotation.

Shortcut refinement

Whenever the destructuring is done in a shortcut refinement declaration, both the keyword and all the types must be omitted. That is, the following are all valid shortcut refinement declarations:

foo = bar

[foo, bar] = baz

foo->bar = baz

Wait. What?

Yes, I know, destructuring for non‐locals, yuck. I’m only adding this for the proposal’s completion sake, because of its regularity. This is a feature you won’t see me defending too much.

Isn’t this more irregular compared to the rest of the language?

Maybe. I think destructuring as it currently exists in the language is pretty irregular by itself, by providing a non‐keyword/type name declaration. One could argue that this, while it makes the destructuring syntax more regular compared with itself, makes it stand out as different and irregular compared to the rest of the language. That’s a reasonable argument in my opinion.

[gavinking]

Thoughts?

@someth2say my thoughts are:

1. For consistency with assert, if, for, etc, the syntax would be value ([x, y] = [1, 2]);, i.e. the parens would go around the whole thing.
2. It’s trivial to parse, indeed, it’s somewhat easier to parse than the current syntax, since value ( can’t possibly be the start of a value declaration.
3. It’s more regular than what we have today, since it’s more similar to the syntax of assert.
4. I have no objection to it.

[zamfofex]

I really don’t understand why you don’t want to discuss this issue, @gavinking. It might not be high priority, but I think it’s important to have something as basic as destructuring declarations be regular.

Additionally, even if you insist it’s “low priority”, it’s not like discussing and trying to solve this problem will cause any sort of harm. Quite the opposite, it might make the language more consistent and overall better.

From the lively arguments the different people are giving, I get the impression that everyone here seems to be interested in continuing to discuss this issue, even if you see it as “low priority” yourself. Even if we disagree on how, it seems to me that everyone is invested in trying to come with a syntax that is better than today’s. I feel like that definitely mean the current syntax is not “perfectly fine”.

Why do you think I spend my time writing these proposals and discussing with people (mainly you) on Gitter? I do so because I care about the language you designed, and I wholeheartedly believe that my proposals can help make it better.

I understand that I’m not the only one collaborating to Ceylon for free, and I know I’m definitely not even close to being the biggest collaborator, but I do what I can do, and what I can do is making suggestions.

I’m really sorry for bringing this up here, but I really feel like I had to say it somewhere — even if I think you won’t want to respond to it here (probably justifiedly).