The "!" in ":!" is not super helpful

[chuanwen]

Look at this code:

fn Partition[T:! Comparable & Movable](s: Slice(T))
     -> i64 {

}

It would be same readable (if not more) if we rewrite to:

fn Partition[T: Comparable & Movable](s: Slice(T))
     -> i64 {

}

The '!' is often associated with concept "logical not", why adding a symbol that does not help in readability.

Note that

var i: i64 = -1;

Without the "!", the single ":" conveys the same high level abstraction: "belongs to", or "is an element of". One can argue that the two "belongs to" (one ":", one ":!") are at different levels: one is type, the other is type-of-type. However, the surrounding [...] syntax can differentiate the two apart.

If we use the single ":" to express the high level abstraction "belongs to", it is nicer to eyes and is easier to remember for new users.

[josh11b]

! in Carbon means "required to be a compile-time constant", and means that parameter may be used in type expressions that need to be resolved at compile time. We discussed alternatives that didn't use ! in #565 . Ultimately this syntax is an experiment, but we do like the clarity we get from having an explicit marker that this is not an ordinary parameter. There is also some precedent for ! meaning something associated with compile-time programming -- for example Rust uses ! to mark macro invocations.

[Turbine1991]

It's going to alienate a few C++ devs.

At least the :# symbol sort of looks like a prison cell. Any alternative characters? 😅 Double ::?

[chuanwen]

Regarding using "!" to mark "compile-time constant": I do understand the reasoning above and it might be reasonable (or even preferred) for an advanced or expert C++ user. On the other hand, for a non-expert C++ user like me, this looks like the implementation details of the compiler that I do not want to learn if not absolutely required.

BTW, for using "!" to mark "compile-time constant", IMHO a more consistent usage pattern would be "T!" to indicate "T" is required to be known at compile-time. Hence the function can be rewritten as

fn Partition[T! : Comparable & Movable](s: Slice(T))
     -> i64 {

}

Note that space between "!" and ":", and there is no space between "T" and "!".

Again, ":" means "is an element of", and the optional suffix "!" means "constant known at compile-time". The optional suffix "!" can be used by library authors and advanced C++ users, while non-advanced C++ users can skip the "!".

[ruler501]

I agree that binding the ! to the variable makes a lot more sense. I don't think it's necessary to restrict whitespace around it though just have it like a suffix version of * on variable names in C++. I could also see it as a prefix since it defines that the variable is known at compile time.

[vdvman1]

I also agree, T:! Comparable absolutely makes me think "T is not Comparable", as I apply the ! to the Comparable.
While T!: Comparable makes me see the ! as just an emphasisis, and I actually correctly attatch it to the T

[m13253]

(Cross-posting with #565)

In my own opinion, the first time I saw [T:! Comparable & Movable], I thought ! means negation (“not comparable”).
If we use ! here, what symbol should we use, if in the future we need to implement, for type negation?

Have we discussed other symbols on the keyboard?

[T:# Comparable & Movable]
[T:% Comparable & Movable]
[T:^ Comparable & Movable]
[T:@ Comparable & Movable]

My personal reasons:

1. The # symbol is familiar to C programmers to indicate preprocessor directives. I think it makes sense to indicate compile-time constraints.
2. The % symbol is used in printf for placeholders, which also makes sense to indicate type placeholders.
3. The ^ symbol doesn't cause ambiguity since xor operator is binary and never occurs at the beginning.
4. I don't have specific reasons for @. But it looks good.

[vbregier]

Or maybe use a keyword ? Usually keywords are clearer than symbols.
consteval ?
const ?
ctc ? (Compile Time Constant)

[pyrbin]

Ive grown to like :: as 'compile-time constants' like how it's done in jai

[m13253]

For C++ and Rust programmers, :: means namespace.
Even if in Carbon we can simply use . for namespace, I don't think it's a good idea to occupy :: for this.
Also there is :!!, and I don't want to see it becoming :::.

[YagaoDirac]

Let me give you an option(edited). In the code
fn Partition[/Notice the scope here/T:! Comparable & Movable](s: Slice(T))
-> i64 {
}
In the scope I emphasis, it's not possible to do any "logic not", and the type has to be figured out in compile time. Or, Carbon does runtime type deduction and create types on the fly????
If I guess the correct answer, then the "!" is simply not needed.
Even if you are to retain it, in your official example, you should write it like
fn Partition[T: !Comparable & Movable](s: Slice(T))
-> i64 {
}
The space should be in front of !.

[m13253]

I'm confused when you say “final answer”. I think this issue is still under debate.
Also I checked you are not in the contributor list of Carbon repo. Did I miss anything?

[YagaoDirac]

Edited. It should be better now.

[gertcuykens]

I also believe :! is to confusing symbol to associate with compile time, I believe the default should be at compile time and when it's not known at compile time it should be indicated by :?

fn Partition[T: Comparable & Movable](s: Slice(T))
compile time

fn Partition[T:? Comparable & Movable](s: Slice(T))
run time

[josh11b]

All regular parameters are going to be runtime, so in your example s would have to be s:?. At the moment, types may not be passed at runtime so the T:? ... part would not be allowed.

[gertcuykens]

For me that would actually make it even better :D because I didn't realise until you mention it so it would even make more sense

fn Partition[T:? Comparable & Movable](s:? Slice(T))

compared to the opposite

fn Partition[T:! Comparable & Movable](s: Slice(T))

[DevNoteHQ]

I would reserve the ? for nullable Pointers, kind of like Kotlin and TypeScript do it.
For now it seems that Optional is prefered, but I really would suggest on using ? as it makes null handling much easier.

[msadeqhe]

As it's explained in #3497, ! means negative, dangerous, warning or surprising. Also ! in Rust doesn't exactly mean compile-time. Would you revisit the decision for :! syntax because of the new information? So many programmers have up-voted this discussion already. It's a data that can be considered. Thanks.

[msadeqhe]

OK. I end up to think in this way. I hope it helps the readability:

• ! before another symbol has negative meaning such as != is "not equals" operator.
• ! after another symbol has compile time meaning (or generally a different meaning than regular code) such as :!.

The position (infix, prefix or postfix) of an operator (symbol) is a common practice to change its meaning.

For example, postfix * means pointer type, but prefix * means dereference operator. Also in Carbon, infix ^ means bit-wise "xor" operator, but prefix ^ means bit-wise "not" operator.

[msadeqhe]

To find a consistent rule with other multi-symbol operators, let's compare ! with =:

• = before another symbol doesn't mean assignment or "equals" such as =>.
• = after another symbol means assignment or "equals" such as += or <=:
  • If the first symbol is arithmetic operation, it means assignment (e.g. +=).
  • Otherwise if the first symbol is logical operation, it means "equals" (e.g. <=).

Considering !=, it means "not equals" because:

• = is after !, so it means assignment or "equals".
• ! is before =, so it has negative meaning, and it's logical, so = has to mean "equals".

Their meanings follow the rules consistently.