-
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] Statement-expressions, result
vs return
#391
Comments
|
If I understand correctly, his is just |
Yes, that's it. Only the syntax is changed to
Also variable capturing, is not needed. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Preface
Statement-expression is a solution to have a group of statements in place of an expression.
I suggest to have statement-expressions in Cpp2 with syntax
: = { ... }
and the result of them are returned withresult
keyword. In this way, the following code:... is somehow equal to the following code except that we don't have to specify the type of arguments:
Statement-expressions can be used to declare variables too:
Suggestion Detail
Currently we declare functions in Cpp2 in the following syntax:
In a similar syntax, we can declare variables in Cpp2 with statement-expressions:
Statement-expressions are unnamed variables in a similar manner that lambdas are unnamed functions:
result
instead ofreturn
within statement-expressions.{ ... }
has the lifetime of that scope.{ ... }
will be executed one time in their place.{ ... }
.Statement-expressions will be not allowed to be used in place of statements. Because it's an error to have an unused value (literal or identifier) in Cpp2:
Expressions, Functions and Blocks
Now
{ ... }
has different meanings in the following categories:: Type = { ... }
is a statement-expression in whichType
can be omitted and deduced from{ ... }
.{ ... }
ends withresult something;
.: (params) -> Type = { ... }
is a function or a lambda in which-> Type
can be omitted if the return type isvoid
.{ ... }
ends withreturn something;
or the end of}
.(params) { ... }
is a parameterized statement block. Whereas{ ... }
is a statement block without(params)
in which()
must be omitted.{ ... }
ends with:}
.break
andcontinue
in loop control structures.result something;
when their outer scope is a statement-expression.return something;
when their outer scope is a function or a lambda.In all of the above categories, they have this similarity:
{ ... }
has the lifetime of that scope.Additinally they have different behaviours in statement execution and variable capturing:
{ ... }
one time in their place.{ ... }
multiple times in any place.{ ... }
.{ ... }
.I should mention that statement-expressions, functions and lambdas, statement blocks and parameterized statement blocks can be nested inside each other.
Your Questions
Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?
Yes. In a way that it helps Xto organize code and separate related statements in nested blocks to easily fix or prevent unwanted bugs which are a result of having mixed unrelated statements together.
Will your feature suggestion automate or eliminate X% of current C++ guidance literature?
Yes. In the following ways:
if
,while
and other control structures as an expression that is more readable in variable assignment, because the intention is clearly written in code, see the example below.Consider how the following code:
... is more readable and generic than the following code which we have to also specify the type of the variable:
Considered Alternatives
Instead of
result
keyword, it's possible to use symbols such as=>
or nothing (like in Rust). For example:... or this one (like in Rust):
Howerver I think that having a keyword like
result
or a notation like=>
, is more readable than having nothing.References
This suggestion is inspired from discussions in this issue and this paper mentioned by @JohelEGP and this informative comment from @hsutter which describes Unifying Functions and Blocks.
The text was updated successfully, but these errors were encountered: