-
Notifications
You must be signed in to change notification settings - Fork 251
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SUGGESTION] Treat a keyword as an identifier #392
Comments
I've actually found the Cpp2-specific keywords to be contextual, except for the
Including the |
You're right 😬, that's very nice but it doesn't work in every situation, for example: type: type = {}
main: () = {
variable: type = 0;
} |
I prefer |
Also Cpp2 may have more keywords during language evolution in the future, therefore keywords such as |
For |
This are the sets of Cpp2-specific keywords: {i8, i16, i32, i64, u8,
u16, u32, u64, i8_fast, i16_fast,
i32_fast, i64_fast, u8_fast, u16_fast, u32_fast,
u64_fast, i8_least, i16_least, i32_least, i64_least,
u8_least, u16_least, u32_least, u64_least, inspect});
{next, copy, move, forward, pre, post, final,
in,
as, is, type,
assert, throws,
implicit, out,
inout}); I can't come up with another example like #392 (comment)'s. |
Thanks. It's a good idea to use helper type main: () = {
type: type = {}
variable: ::type = ();
} |
Well, the only reason to name it |
Perhaps a backslash prefix would be a little more readable.
|
Makes me think if raw string literals could just be backslash-escaped (see #302). |
@MichaelCook, I like the idea to use backslash syntax Escape sequences in string literals start with a backslash to change the meaning of a character, why not just use it to change the meaning of a keyword and treat it as an identifier? @JohelEGP, Good idea but in my opinion, raw (non-interpolated) string literals break the general capture syntax |
Because it only works on keywords, if Cpp2 has binary operator // Treats `type` keyword as identifier.
x: \type = ();
// binary operator \
y: = var0 \ var1; Also unary prefix and postfix operators |
These are other use cases and reasons why it does matter in addition to C and Cpp1 language interop:
variable.\if(count < 10).\return(); |
Could you give an example C++ API that would not be usable from Cpp2? Naming variables is not such a case. |
How's this:
|
See #392 (comment).
|
Also Cpp1 type traits in standard library have a member type named std::is_integral<T>::type |
Also const: type = {}
main: () = {
x: const = "";
} But it works with qualified name. By the way Cpp2 generates invalid Cpp1 code: const: type = {}
main: () = {
x: ::const = "";
} |
According to @JohelEGP's helpful comment:
If Cpp2 accepts all keywords as identifiers with qualified names, and if Cpp2 would allow a way to have qualified names for local declarations (e.g. // `while` is not a keyword, because it's left-hand-side of `:`.
while: type = {
// `return` is not a keyword, because it's left-hand-side of `:`.
return: () = {}
}
main: () = {
// `do` is not a keyword, because it's left-hand-side of `:`.
// `do` is a local type.
do: type = { /* definition */ }
// `_::do` is a qualified name.
variable: _::do = /* definition */
// `for` is not a keyword, because it's left-hand-side of `:`.
// And `while` is an identifier.
for: ::while = ();
// `for` is an identifier becuase there is an operator dot.
// And `return` is an identifier too.
for.return();
// Also to clarify, `for` may be required to be quialified, but it's a little restrict.
_::for.return();
// `for` is a keyword, because there isn't any operator between `for` and `args`.
for args do (arg) { /* statements */ }
// `return` is not a keyword, because it's left-hand-side of `:`.
return: (param) -> ::while = ();
// AMBIGUOUS!
// When there is an ambiguous, they are keywords.
// So `return` is a keyword here.
return(/* something */);
// This `return` is not a keyword, because its name is qualified.
_::return(/* something */);
// `if` and `for` are not keywords, because there is an operator between them.
value: = if * for;
// `do` is not a keyword, because it's already a qualified name.
my_namespace::do();
} In this way, keywords would be fully contextual (except for EDITThis way has a problem if Cpp2 supports operator overloading for // This is AMBIGUOUS:
// Is `return` an object with `operator""`?
// Or is `return` a keyword and returns string `"something"`?
return "something";
// This is OK. `return` is an object with `operator""`.
_::return "something"; It is similar to how |
To simplify the rule, maybe Cpp2 should require that every identifier to be qualified in which their name are equal to keywords: // `_::` must be omitted for naming declarations.
while: type = /* definition */
do: _::while = /* definition */
// `_::` must be omitted for accessing members with :: or dot.
// Because these are already qualified names.
_::do::type.as.forward;
_::return(args);
// OK. Keywords cannot be qualified names.
value: = _::if * _::for;
// `inspect` is not a keyword, because it's already a qualified name.
my_namespace::inspect(); So they must be always qualified either Instead of |
Another option to consider is Types, functions and variables can be templates already. So if: (condition: bool, forward yes_value: int, forward no_value: int) -> forward int = {
/* Or force the template notation <> within declaration:
if: <> (condition: bool, forward yes_value: int, forward no_value: int) -> forward int = {
*/
if condition {
return yes_value;
}
else {
return no_value;
}
}
if: <T> (condition: bool, forward yes_value: T, forward no_value: T) -> forward T = {
if condition {
return yes_value;
}
else {
return no_value;
}
}
main: () = {
// if<> is not a keyword here.
x: = if<>(2 * 2 == 4, 1, 0);
// if<bool> is not a keyword here.
y: = if<bool>(2 * 2 == 4, true, false);
// if<> is not a keyword here.
z: = (2 * 2 == 4).if<>(1, 0);
} But keywords cannot be templates, so template arguments after keywords, mean they are not keywords. This requires empty template argument list as described in this bug. |
Also it depends if Cpp2 would have similar Cpp1-style Or would Cpp2 have stand-alone if <something> { ... } That's suggested in this issue. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Preface
I suggest to use
"keyword"$
syntax to treat keywords as identifiers in Cpp2.Suggestion Detail
Some identifiers in Cpp2 are keywords in Cpp1 such as
and
,or
, etc. These identifiers aren't valid identifiers in Cpp1. Therefore Cpp2 appendscpp2_
prefix to these identifiers during code generation for Cpp1 as discussed in this issue. For example identifiersand
,or
, etc in Cpp2 will respectively become identifierscpp2_and
,cpp2_or
, etc in generated Cpp1 code.On the other hand, some keywords in Cpp2 aren't keywords in Cpp1 such as
type
,next
, etc. These keywords are valid identifiers in Cpp1. Therefore it's not possible to use such identifiers in Cpp2 when dealing with Cpp1 API:I suggest to use a syntax such as
"keyword"$
to access identifiers from Cpp1 API in which they are keywords in Cpp2:I think syntax
"keyword"$
is good enough because Cpp2 will have similar syntax for reflections and code generations as described in this page of Wiki. And semantically this is related to them.Your Questions
Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?
No.
Will your feature suggestion automate or eliminate X% of current C++ guidance literature?
No.
Considered Alternatives
I considered to use syntax
@keyword
but it would resemble meta-class functions. Another possible syntax is@"keyword"
, which doesn't resemble meta-class functions in addition to its difference from capture syntax.Also we can use a prefix such as
cpp1_
. For example:In this way,
cpp1_
prefix in addition tocpp2_
prefix should be reserved for Cpp2 compiler, and user-defined identifiers with those prefixes shouldn't be allowed.By the way, treating a keyword as an identifier, isn't frequency needed to dedicate a new symbol to it.
EDIT 1:
keyword<>
is another alternative solution as described in this comment.The text was updated successfully, but these errors were encountered: