Confusing syntax for generic parameters

[DavidPoliakoff]

I have a problem with the syntax, but don't know enough to propose a good solution, so I wanted to raise this here.

In this section we get our first example of a generic function

fn SortVector(T:! Comparable, a: Vector(T)*) { ... }

And are told that the ! means it's a generic function. I had the strong instinct, as have two of the devs I've shown this to, that we're saying that T is "not" (!) Comparable.

Is there a reason for the use of the ! token, here? Absent any constraints around parsing (could it be mistaken for a ternary) I think Java uses ? sometimes for this, but really just most tokens other than ! feel slightly better.

[KateGregory]

Note that we are using not for negation. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/expressions/logical_operators.md

[DavidPoliakoff]

So, that's certainly true, but if you're coming from another language and reading this, your brain will say not. I'm okay if as a group this gets closed with "that's okay, you should remember that not is spelled not rather than !" but just from a gut-check, I suspect this will be a really common stumbling block for people coming from C++

[tkoeppe]

In CSS, ! important means "this is important", not "not important". In Rust foo! means "here's a macro".

Ultimately, I think syntax is something one can get used to. It's not like you would try to guess the meaning of a piece of code without a reasonable level of command of the language (or at least that's not a use case of particularly high priority).

It's novel, sure, but maybe we can revisit this once there's a bit more Carbon code in the wild and we can see how some concrete alternatives measure up?

[DavidPoliakoff]

I'm inexperienced with language design, so this is asked out of ignorance, but once there's code in the wild, doesn't it become much more expensive to change? If I'm wrong about that, then sure, try it and see, ignore the rest of this comment.

I think Rust feels a bit different in that it's postfix, as so it won't have that same impact. And I think CSS is different enough that I'm not too worried about people coming from CSS to Carbon and having cognitive load, they'll have a million things to learn, I'm not worried about a million and one.

I'd recommend checking whether the ! is a conscious choice of a good token, or just a holdover from somebody saying "I dunno, maybe use !." If it's just something that happened, maybe rethink it, is some other token going to hurt us? If it was reasoned about, is there some other token that meets the constraints?

This is a P3 in my mind, not a five-alarm fire, I just want to make sure we're consciously choosing these things, given that the devs I've shown this to have had the same take.

[geoffromer]

I'm inexperienced with language design, so this is asked out of ignorance, but once there's code in the wild, doesn't it become much more expensive to change?

One of our main goals for the project is to preserve our ability to change the language in response to new information.

I just want to make sure we're consciously choosing these things, given that the devs I've shown this to have had the same take.

It was a conscious choice. See #676 and the issue it references for the reasoning behind this decision.

[DavidPoliakoff]

Yeah, I guess I just found this comment pretty compelling. I looked at a few of the threads linked (not all, it's a pretty branchy tree) and it looks like the reasoning behind ! is that "this is how Carbon says 'required to be compile-time constant,'" which is true, but I don't think will help the dissonance for new devs. But it looks like this is an understood thing, so I'm comfortable if you want to close this and just have it in mind as data the next time we're making a conscious decision on this syntax.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.