On return type syntax

[kfsone]

I perhaps understand why you chose ->, but I don't see this as a specially safe choice. Someone working between languages
has lots of additional cognitive load trying to track the current context of what this means.

There are several obvious ways you could simplify this for reader/writer/parser: main: (args) -> int = {} as perhaps main: (args): int = {}, main: (args) int = {}, main: (args) = int: {}, or main: (args) = int {}.

I feel though that the spirit of this project calls for repeating a pattern you already called out for its superior safety:

main: (args, return: int) = {}

For example:

...
    protected parse_statement: (
        inout this,
        copy source: std::string_view,
        return: std_unique_ptr<statement_node>
    )
...

[JohelEGP]

main: (args) int = {}

I think this is the only viable candidate among your proposed ones.
Most others use :, which is already used to introduce a name (or unnamed value).

The last one, without :, moves the return type to the initializer.
I don't think that's a good move.
I like to think of everything between : and = as the "signature" of the (un)named declaration.

[JohelEGP]

compare_distances: (Point origin, candidates: std::vector<Point>, return furthest: Point);

I think you'll need a better example.
As I'd rewrite this to:
furthest: (origin: Point, offsets: std::span<Point>) -> Point;.

[kfsone]

I've removed the annecdotal opine on named returns as it's not pertinent to the syntax change.

[JohelEGP]

There's some overlap with #540.

[kfsone]

This is about the syntax, the pitch for naming returns and multiple returns is definitely independent, excepting that this syntax change doesn't interfere with or depend on those changes.

[JohelEGP]

This is only about syntax.
But the changes suggested there very much affect syntax.
After all, it started out as making the return type be an out parameter.

[JohelEGP]

After all, it started out as making the return type be an out parameter.

It was the reverse, actually.
And it encourages the ->.
I suppose you're right in that they're independent.
After all, they could be moved back as you suggest:
f: (return (name1: i32, name2: i64));,
or something like that.

[gregmarr]

Why would you want to do this? Deduplication.

get_local_time: () -> time_t = {
    time_t now;
    ...
    return now;
}

vs

get_time: (return now: time_t) = {
    ...
    return now;
}

Okay, but the current syntax with named returns is this, which is even less due to implicit return:

get_time: () -> (now: time_t) = {
    now = ...;
}

[hsutter]

An important thing to keep in mind is declaration-use symmetry. I mentioned this in the Design note: Postfix operators. Consider examples like this:

f: (i: int) -> *string = ...

where as we add to the expression, we just move items from the rhs to the lhs:

expression  type
f           (int) -> * string
f(42)                * string
f(42)*                 string

I realized that the -> is grammatically redundant in the declaration syntax -- for a while I omitted it. But it felt like the -> had readability value (and follows Cpp1 and most languages). In particular, separating the parameter list and the return value list was visually important.

For example, consider:

g: (i: int, j: int) -> (name: string, addr: string) = ...

It would be grammatically unambiguous to omit the -> and instead write it as:

// Not Cpp2, but an alternative syntax I did try
g: (i: int, j: int) (name: string, addr: string) = ...

but to me that that just felt surprisingly harder to read.

[nigeltao]

expression  type
f           (int) -> * string
f(42)                * string
f(42)*                 string

I don't know if it's the point you were trying to make, but the -> there sticks out as inconsistent (unlike * or (), it's only on the first line) with what's otherwise a very regular pattern.

But it felt like the -> had readability value (and follows Cpp1 and most languages)...

g: (i: int, j: int) -> (name: string, addr: string) = ...

Go omits the ->, although admittedly has a func keyword. Here's a runnable example:

package main

import "fmt"

func main() {
	g := func(i int, j int) (name string, addr string) {
		return "alice", "home"
	}
	fmt.Println(g(7, 8)) // Prints "alice home\n"
}

Like i: int versus int i, "harder to read" might just be "unfamiliar".

[JohelEGP]

I think punctuation is important otherwise readability is lost do you get my drift

[kfsone]

Yes" but,the punctuation! you use; shouldn't be. arbitrarily: selected" characters.

We're not here because C++ has improved only for the better between 11-20. I posit that the large influx of non-C-based and often functional programmers onto the committee resulted in a skew towards adopting C-alien paradigms because there has always been a "not invented here" guard on the committee that tries to detect and shoot down anything that sounds like Java (or, ...) but these wholly unfamiliar concepts slipped past that particular firewall.

I too found Go's function syntax initially hard reading, and it's still a point where I think Go fails to live up to it's "beautiful" claims. But still find it preferable to using a pointer dereference.

t: int = (s) -> (st_size);

f: (s: *S) -> (int);

I'm responding not to <identifier> TOK_COLON <method parameters> TOK_RETURN_TYPE ...., but to TOK_RETURN_TYPE being the same as TOK_C_POINTER_DEREF.

Here are similar collisions to emphasize the collision aspect itself:

f: (i: int) * (int)
f: (i: int) >> (int)
f: (i: int) <-  (int)  // somehow feels like a more correct 'handedness' in the context of a C-based language
f: (i: int) == (int)
f: (i: int) , (int)
f: (i: int) ! (int)
f: (i: int) return (int)  // the least frictious to me, but I suspect the most irksome to many, and possibly has a performance impact on parsing complexity.

[JohelEGP]

Times have changed, along with opinions: #714.

[SebastianTroy]

I have to say, neither syntax is familiar to me, but reading in phone, with lots of automatic line wrapping muddling the picture, the punctuation really helps me to parse what is going on at a glance, without actually reading every character and thinking about it. The punctuation gives my eyes places to jump to, and context to quickly ascertain what neighbouring tokens mean without breaking my flow, I don't know about you, but if I have to think too hard about every little bit of code, I find it harder to see the bigger picture, making the code easier to parse by eye really helps with this in my personal experience. On 31 August 2023 03:15:21 Nigel Tao ***@***.***> wrote: expression type f (int) -> * string f(42) * string f(42)* string I don't know if it's the point you were trying to make, but the -> there sticks out as inconsistent (unlike * or (), it's only on the first line) with what's otherwise a very regular pattern. But it felt like the -> had readability value (and follows Cpp1 and most languages)... g: (i: int, j: int) -> (name: string, addr: string) = ... Go omits the ->. Here's a runnable example<https://go.dev/play/p/6O8KKbHnDWf>: package main import "fmt" func main() { g := func(i int, j int) (name string, addr string) { return "alice", "home" } fmt.Println(g(7, 8)) // Prints "alice home\n" } Like i: int versus int i, "harder to read" might just be "unfamiliar". — Reply to this email directly, view it on GitHub<#618 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQIQRW6HVL2OFX6ME5LXX7XTNANCNFSM6AAAAAA4B6OMP4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AbhinavK00]

One argument here is about Go, which doesn't have -> and therefore its cognitive load for someone working between languages. But same point could be used against this suggestion if the user was working with, say, rust or cpp (kinda).
Another point I'd like to make is that, like Herb, Jai language's creator also made the decision to keep -> even if it wasn't needed.
But, not using -> will probably have it reserved for use in other places in the languages (like code injection maybe).
Just my 2 cents.

[realgdman]

I feel it rather reduce cognitive load,compared with situation where similar char, say I need more time parsing string, where : means different things in different parts.
Also -> arrow is pretty known in academic circles about computer languages, it has meaning something like "take from left and convert/process to right" applied to types/functions, so it doesn't feel foreign to me.