syntax sugar for "named tuples" in feature results

[maxteufel]

see #3276 for the motivation behind this. it would be nice, if

  cut(sep String) (before, after String, found bool) =>

was syntax sugar for

  cut_result (before, after String, found bool).
  cut(sep String) cut_result =>

what's the opinion of everyone on this? @tokiwa-software/developers

[michaellilltokiwa]

So the type of the result in the first example should also be cut_result or some internal type that can not really be used as a type?

[michaellilltokiwa]

Aside from this, some mechanism like this might alleviate my main issue with tuples.

[fridis]

Few points from me

• what features should our tuple type define, what properties should it implement? It would be convenient if, e.g., tuples would automatically be equatable, orderable, hashable, as_string, etc. if their elements are.
• then, should named tuples inherit from tuple and have the same magic? Probably yes.

I fear that it will be difficult for the parser to distinguish a tuple type like

x (i32, list u8, option bool) => abstract

from a named tuple

x (before, after String, found bool) => abstract

Also, if there is not explicit name, how can we create a value of that type, e.g.,

cut(sep String) (before, after String, found bool) =>
  tmp := (get_left sep, get_right sep, contains sep)
  if debug
    say "cut {String.this} but $sep is $tmp"
  tmp

What type should tmp be?

What I imagine is more like this

cut_result(redef before, redef after String, redef found bool) : tuple before after found
  rename
    values.0 as before
    values.1 as after
    values.2 as found
is

which is very verbose, but could be the basis to then think of adding syntax sugar to shorten this.

For now, I think I prefer adding explicit features likecut_result in #3276.