Immutable value semantic returns questions from #5434

[josh11b]

These questions were prompted by discussion around proposal #5434 .

How should we spell value form returns at a high level? Should we have

• an explicit marker attached to the return?
• an explicit marker attached to the function declaration? or
• imply this from bound parameters?

If the answer is one of the first two, should the explicit marker leverage the keyword let? If not, what keyword or symbol should be employed here?

If we do pick the keyword let, should we rename terminology to use that keyword as well? And how much terminology?

[chandlerc]

Note that these questions (in addition to some others) were discussed in the open discussion, with notes that folks interested can dig through here: https://docs.google.com/document/d/1Yt-i5AmF76LSvD4TrWRIAE_92kii6j5yFiW-S7ahzlg/edit?tab=t.0#heading=h.uot97ukynlsi

[josh11b]

Some other ways of writing returns were discussed in the "Other syntax for compound return forms" section of #5434, and #syntax on 2025-05-14.

• An argument for the first option is immutable value returns shouldn't be the default, since it imposes an additional requirement that referenced parameters are marked bound.
• An argument against the second option is that we want to control this on a per-return basis when there is a compound return.
• The third option was argued against in the "bound would change the default return to let" alternative in ref parameters, arguments, returns and val returns #5434.

The proposal uses let to avoid introducing a new keyword, since the arguments that led to us using let in the first place still apply. Most notably, we already rejected val as being too similar to var, with a particular concern for Japanese speakers that don't distinguish L and R.

[chandlerc]

Building on the return syntax change I suggested in the review of #5434 here, I'd like to suggest a potential direction for this that I think I'm starting to like.

---

I think the answer to the question should be (1).

And I'd like to suggest that the keyword should be val rather than let, but that it is used very differently from let and somewhat differently from var. I believe this was actually @geoffromer 's suggestion from the review of #5434 but I misunderstood that until he clarified in an open discussion to imply val being used more broadly.

Specifically, I'd like to suggest that we have two keywords ref and val that only modify expression category, and are always used tightly-bound to the type of the expression taking on that expression category.

For patterns, ref always applies to a binding, not an entire sub-pattern. And similarly in a return, ref applies to a single type expression, not to a compound return of any kind.

Where the proposal with my adjusted syntax above uses let, I'm suggesting we use val and give it a parallel model to ref. In a return, it applies tightly to a type expression. If we want, we can allow val in patterns as well, but it's not clear there is a motivating use case. I believe it would be redundant everywhere except something like var (x: i32, val y: i64), and this hasn't so far been a motivating thing to support. But it might be cleaner to allow it for orthogonality.

Neither ref nor val would ever be introducers for a declaration though, in part because they never introduce an entire pattern and all of our declaration introducers do.

The canonical introducer for a local pattern would remain let. This also ties nicely to at least my understanding of where the word 'let' comes from here: it is about attaching names to things, and so seems especially odd in returns where there are no names.

The pattern operator var would remain a bit odd in two ways:

• We would support a shortcut of var ...; for locals (and analogously for members) instead of let var ...;.
• We would re-use var for a tight-binding type expression modifier in returns.

The first of these two oddities doesn't bother me. var still introduces an entire new pattern context, so this isn't stepping away from that. And the prevalence of this use case IMO warrants making it convenient.

The second of these oddities is argued against by all the reasons I suggest to use val instead of let above, but I think it is a significantly less strong argument on almost every count for me. As a consequence, it doesn't quite rise to motivate a new keyword (possibly init). But if others felt strongly, I'm open to splitting out the return usage to a different keyword.

The historical concern with val was its similarity with var. However, with this suggestion that would only come up in exceedingly rare cases. val-qualified return types are expected to be relatively specialized which is why they are not the default. And return types that need an explicit var qualification because they start with ( or { but don't want compound return semantics is likely even more rare. Nearby code using both that suffers from visual or auditory similarity of these keywords seems like a much more minimal concern.

Putting these suggestions together with my comment at the top from #5434 this would give us:

// `->` begins a "return form", whatever the right word
fn F()     -> <return-form>;

// Within any return form, there are N syntactic overrides where the thing following
// the arrow *does not* form a type expression
fn Let()   -> val <type-expr>
fn Ref()   -> ref <type-expr>
fn Var()   -> var <type-expr>
fn Paren() -> ( <return-form>, ... )
fn Brace() -> { .<id>: <return-form>, ... }

// Otherwise, implicit `var`:
fn Other() -> <type-expr>

// Could add `val` before `<id>` here but it would be redundant.
let (<id>: <type-expr>, ...) = ...;

// Could allow `val` as below, but seems of minimal utility. Would
// force the initializer to exist.
var (<id>: <type-expr>, val <id>: <type-expr>, ...) = ...;

This would tie us more firmly to not using let in the terminology such as let-expressions or let-semantic bindings. It would instead commit us (even more) to value-expressions, but might allow us to in some cases further differentiate it from casual collisions with C++'s by-value, actually by-move-or-copy, parameters by calling things val-expressions or val-semantics. I'm indifferent about "val-" vs. "value-".

---

All this said, if val specifically is something there is no consensus around, my second choice would be all of the above but with the let keyword (which is roughly #5434 with my suggested syntax adjustment). Options (2) and (3) are significantly less appealing to me after reading all the arguments here.

[geoffromer]

I believe this was actually @geoffromer 's suggestion from the review of #5434

Yes, this is what I was trying to describe, except that (following the state of the discussion at the time) I didn't expect there to be an explicit var in the return syntax. For what it's worth, I'd prefer init over var if an explicit syntax is needed, so that the return syntax consistently refers to expression categories using keywords that correspond to the category names.

[chandlerc]

One of the concerns with using val as a keyword was that it could be problematic to distinguish from var for non-English speakers. A specific example given from Japanese: https://en.wikipedia.org/wiki/Perception_of_English_/r/_and_/l/_by_Japanese_speakers

I posted a question about this specifically on social media and several folks were kind enough to reach out to a few Japenese developers who helped clarify that that this isn't significant problem in practice -- there is a near-universal way of transliterating these into Japanese that would distinguish these effectively. It might be a minor stumbling block for Japanese and English devs conversing about these keywords extensively and without sufficient context, but everyone seemed to think this wasn't a huge deal. For example: https://mastodon.social/@amake/114696079472658540

The larger issue seems to be the core visual similarity. That definitely is an issue, but at least for me seems much less worrisome in the context at hand: val would be relatively rare and for a specialized purpose, var in the same position vanishingly rare, and in either case part of a larger signature and not one of many introducers where visual distinction in rapid scanning is essential.

My personal sense is that in this context, having good mnemonics and associations with the underlying semantics seems likely more important than the confusion factors. Curious how others feel here though.

[chandlerc]

A separate thing that came up in open discussion and I wanted to reflect here: the impact of these keywords on interop.

I looked both at LLVM's codebase and also at all the codebases (both internal and open source) that we have indexed at Google for easy searching. I didn't find any sharp differences in the ratios between LLVM's codebase numbers and the others.

• val is a surprisingly common identifier in C and C++ code. More common than all the other keywords we are discussing here.
  • 2x or more common than var
  • value is 5x - 10x more common than val
  • Vast majority of val identifiers are not in APIs -- local variables or private members, etc.
  • Usages seem very amenable to heuristic renaming -- no semantics attached, easy to say val -> value, especially given the prevalence of value.
• init is similarly common to val (a bit less common in Google's code, a bit more common in LLVM's)
  • Many of the init identifiers are in APIs
  • Used to abbreviate different things, no clear way to extrapolate a longer form

So val is a bit expensive to take as a keyword, but probably not as bad as it looks due to the usages being both less a part of APIs and unusually amenable to renaming during something like a migration.

But init is probably very expensive to take as a keyword. Not impossible, but costly.

[chandlerc]

Based on everything I've seen so far, my preference is largely what I wrote in the comment above:

• val to explicitly request a return that forms a value expression in the caller
• var to explicitly (when needed due to ambiguity such as a tuple type) request the return form to be initializing.

The cost/benefit of adding val as a keyword rather than reusing let, to me, looks to me to be a net positive.

To me, the cost/benefit of init vs. var doesn't end up positive, both due to the higher cost and lower benefit, even though the structure and nature of the comparison is similar.

[zygoloid]

Closing as decided per @chandlerc's previous comment.