Allow reserved identifiers as Attribute names?
To be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. This also means that naive code generators can just generate the D code in quoted form all the time and not have to worry about special cases, and only when users hand-write the D code they can leave the quotes out for typical cases.
Quote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like [cumulative salary taxable amount] when cumulativeSalaryTaxableAmount would be just as readable without festooning the code with eye-watering delimiters.
Quote from Dave Voorhis on December 22, 2024, 4:52 pmQuote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like
[cumulative salary taxable amount]whencumulativeSalaryTaxableAmountwould be just as readable without festooning the code with eye-watering delimiters.
Yes, that is how SQL works, except typically it is quotation marks, eg "foo" for identifiers and 'foo' for regular character string data.
However, your counter example is even MORE of an abomination because there are no separators between the words and your casing is inconstant, making the first word all lowercase while capitalizing the others. The best names would be like cumulative_salary_taxable_amount, which both avoid the delimiters AND all the problems with your alternative.
Quote from Darren Duncan on December 22, 2024, 11:03 pmQuote from Dave Voorhis on December 22, 2024, 4:52 pmQuote from Darren Duncan on December 22, 2024, 5:34 amTo be clear, I'm proposing that quoted is the default natural syntax for identifiers, and that writing identifiers non-quoted is just a common supported shorthand for when that shorthand isn't ambiguous. ...
Isn't that the usual approach for SQL implementations?
It leads to abominations, such as column/table names like
[cumulative salary taxable amount]whencumulativeSalaryTaxableAmountwould be just as readable without festooning the code with eye-watering delimiters.Yes, that is how SQL works, except typically it is quotation marks, eg "foo" for identifiers and 'foo' for regular character string data.
However, your counter example is even MORE of an abomination because there are no separators between the words and your casing is inconstant, making the first word all lowercase while capitalizing the others. The best names would be like cumulative_salary_taxable_amount, which both avoid the delimiters AND all the problems with your alternative.
Ah, the eternal camelCase vs under_scores debate. All we need now is a good emacs vs vi argument (along with a dozen or so of the usual TTM forum quarrels) and the cycle will be complete.