Choice of -> over =>

[seanlowe]

As someone who is primarily codes not in C++ but in PHP and the JS suites, what was the logic behind choosing to use the skinny arrow over thick arrow for function declarations?

fn main() -> i64 { ... }

Based on the Carbon docs for pointers:

Dereference: given a pointer p, *p gives the value p points to as an l-value. p->m is syntactic sugar for (*p).m.

Won't using -> in both places cause confusion? Would using => be better for function declaration simply because people who have used other languages will more easily recognize it?

[jwtowner]

C++ uses -> for trailing return types already, it was added way back in C++11.

[seanlowe]

Ah, I did not know that. After doing a little research, I can understand why you would want to use trailing return types but I feel my original question still remains.

It seems to me that part of the Carbon's purpose is to build a sensible, maintainable language with modern features to succeed C++.

In the repo's main README, it says:

The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax.

Using the skinny arrow both for syntactic sugar with pointers and with trailing return types lends itself directly against consistent, simple syntax. In that light, wouldn't changing the operator for trailing return types be a reasonable decision?

[jwtowner]

There are multiple goals to consider. I believe Carbon is intended more as a language for those coming from C++, with existing legacy codebases already written in C++, for which they would like to migrate to a more modern language over time.

Also from the README:

Fast and works with C++
Performance matching C++ using LLVM, with low-level access to bits and addresses
Interoperate with your existing C++ code, from inheritance to templates
Fast and scalable builds that work with your existing C++ build systems

Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead.

With this approach, we can build on top of C++'s existing ecosystem, and bring along existing investments, codebases, and developer populations. There are a few languages that have followed this model for other ecosystems, and Carbon aims to fill an analogous role for C++:

JavaScript → TypeScript
Java → Kotlin
C++ → Carbon

[lexi-nadia]

I'm not aware of any languages that use => for return type annotations. -> has a long history, going back at least to Miranda.

The C/C++ -> member lookup operator is not common in other languages, either. It's arguably a historical accident. If the B language had used ptr* instead of *ptr as the dereference operator, then C might have used foo*.bar instead of foo->bar. That said, it exists, and C++ developers might be surprised if Carbon didn't support it.

If we want to maximize familiarity for C++ developers, then i think we should match what C++ does, and use -> for both cases. If we want to have a cleaner syntax even if it's less familiar, then i think we should use -> for return types (like many other languages), and get rid of the arrow operator (which is almost unique to C/C++).

[emlai]

Or, to make return type annotations consistent with other type annotations, : could be used:

fn foo(x: i64): i64 {
    ...
}

Two existing successful successor languages, TypeScript and Kotlin, use this syntax.

[GiorgosAlexakis]

You should post this

[GiorgosAlexakis]

I think it would be even more readable if basic types had longer names:

fn foo(x: int64): int64 {
...
}

[emlai]

The : vs -> return type syntax has been discussed a couple of times in Discord, for example.

But considering the upvote ratio of my comment, : seems to be more popular, so making a proposal could be worth it.

[emlai]

@GiorgosAlexakis Created a poll for that: #1696

[pache-Ak]

I suggest use fn name(args) return-type { } in issues #1600. Go use this syntax, it is concise than others. but #1600 not be accepted. I get a reply said a simple fact that C++ uses this exact syntax for its trailing return types. They think the consistency alone makes an extremely strong argument for the syntax we have. I agree this change is not necessary. But I don't agree the consistency is a good reason.

[geoffromer]

So far, we haven't had any reports of confusion (or parse ambiguity) between the two meanings of ->, but that may change when we start trying to design the syntax for function types. If the double meaning does turn out to cause a problem, the return type syntax is probably what we should change. The -> return type syntax is much less common, and much less deeply rooted, than the -> member access syntax in C++, so it will be a much easier habit for C++ programmers to relearn.

[OlaFosheimGrostad]

@geoffromer I disagree with this view. ->is a strong visual marker and makes expressions noisy. IIRC -> has the two meanings in formal notation: assignment or return type. Perpetuating C's semiotic design mistake is not optimal.

It is better to replace C's -> with .., or consider auto-dereferencing, so you get more consistent visual syntax for field access.

Using : as a return type marker is consistent, but not good for usability as it makes it harder to find the return type in complex signatures, in my experience. C++ code often has complex signatures and I would expect this to be the case for Carbon too. The return type is the most important aspect of a signature, so there are good reasons to make it stand out.

Please keep -> as the return type marker, it is a strong visual marker, consistent with formal notation and consistent with modern C++.

[OlaFosheimGrostad]

Examples that show why '->' is bad for usability in expressions:

a->b<-c
a->b>-c
a>-b->c

[EchoPouet]

IMHO, to be consistent with the syntax when define a type in declare variable, the good syntax is :. For me, it's better to be logic with the syntax rather than to be close to C++ syntax.

In the ReadMe:

The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.

So, don't do the same errors also for the syntax.

[emkkla]

Or why not instead keep the iconic "type name" syntax? It's meant to be a c++ successor but it looks more like a wanna be Rust project.

[lexi-nadia]

@EchoPouet From a pure consistency approach, i think the right choice is ->. Imagine if you were writing a function type in isolation:

fn Sum(a, b): (i32, i32) -> i32 {
  return a + b;
}

The type of a function is a function type (with both inputs and outputs), not just its return type. So if a colon were used, but the thing that followed the colon weren't the function's type, i think that would be less consistent; you'd have to use a different syntax for expressing function types (e.g. for callbacks) than for defining functions.

You could imagine using a colon anyway:

fn Sum(a, b): (i32, i32): i32 {
  return a + b;
}

But in that approach, colon is being used for two different things -- it's the "type annotation" character and the "return type" character. To me, that seems like it would be more confusing.

It's worth noting that -> for return types is found in many languages, not just C++.

[lexi-nadia]

@emkkla : Hi! The Carbon community isn't a place for insulting languages or software projects. Let's stay focused on the technical issues at hand. Thanks for understanding. :)