Make `class` a contextual keyword

[mateusfccp]

Currently, class is a reserved keyword. Because of this, we can't have variables or fields named class. It's common to see people using funny alternatives like klass, clazz or class_.

This issue is a suggestion to make class a contextual keyword, so it's only "reserved" when declaring a class: class Name { /* ... */ }. It's not something that enables or facilitates users to do something, but more of a quality-of-life change.

As far as I can tell, this would be a non-breaking change. I am not aware if this change would have any relevant implications for the language.

[lrhn]

The parser is probably very happy that class is a reserved word. If it sees final class it knows it's not seeing the start of a variable declaration.

If we made class a built-in identifier instead, I think it's currently unambiguous whether a sequence containing class is a class declaration or not, it just needs more look-ahead to determine which it is.

(Making it a "contextual keyword" usually requires an unambiguous prefix to set the context, and class can occur at the start of the production.)

[MarcelReiter]

"class" is an abysmal variable name. We shouldn't "fix" dart, but rather the naming scheme of these people

[lrhn]

It's sometimes a very fitting name when you're writing a compiler. Or, more widely relevant, a macro.

[mateusfccp]

It's sometimes a very fitting name when you're writing a compiler. Or, more widely relevant, a macro.

This is exactly my case. I'm writing an interpreter in Dart and had this "issue", but I remember also thinking this when I was writing a build_runner program.

[Levi-Lesches]

My first introduction to Flutter and Dart was in making a scheduling app for a school that had a separate term for Course, Section, and of course, Class. As much as I wish I could've been able to say final class = getClass(student), I do think it's best to bite the bullet and use something like class_.

Keeping the language parser (and team!) happy is one thing, but when you're writing code there is a relevant difference between referring to a variable or class. It's similar to why you wouldn't want to use for as a variable when writing, say, an e-mail client. It's relevant, but it's also an already loaded term in programming, so you have to be careful.

[ghost]

classon ? (a real word and sounds funny)

[TekExplorer]

as far as I can tell, "final class" is the only ambiguity, right? Could we only allow using the word class as non-global variables? alternatively, we just check if its a valid variable. if not, its probably a class.

[mateusfccp]

as far as I can tell, "final class" is the only ambiguity, right? Could we only allow using the word class as non-global variables? alternatively, we just check if its a valid variable. if not, its probably a class.

I think we should have to disallow a class called class:

class class {...} // Error

This way, the following would be unambiguous:

• final class;: meaning final dynamic class;
• final class = Class();: meaning final Class class (inferred);
• final Class class;: meaning itself;
• class Class {...} or final class Class {...}: defining a class. As class can't be the name of the class, final class Class can't be a variable with type class and name Class, so this would be the univocal syntax for defining a class.

[munificent]

As someone who writes lots of compilers, interpreters, and other metaprogramm-y things, I have definitely run into the annoyance of reserved words.

At the same time... reserved words really do make a lot of things easier technically. If nothing else, it makes syntax highlighters much easier. (In practice, most syntax highlighters I've seen treat every contextual keyword as if it was reserved, which leads to really confusing coloration when you do use the identifier as a regular identifier.)

I can't see us un-reserving class, so I'm going to go ahead and close this out.