a***@gmail.com
6 years ago
Not sure what tone to write this in, but this is a problem that I think
needs to be addressed, and would like some feedback regarding the issue and
this proposed solution.
I also did not see this anywhere else, but if it is redundant, please let
me know.
*Currently the auto keyword is required to use a trailing return (except
with lambda functions).*
*However, auto can also be used without a trailing return to auto-deduce
the return type.*
*This can lead to errors if a trailing return is unintentionally forgotten,
which could then cause difficult to locate unintended behavior.*
*I'd like to discuss a keyword that required that the function return type
should be specified though a trailing return.*
The keyword would take on a subset of the auto keyword's behavior. Similar
to the auto keyword, it would look for the trailing return.
However, it would not auto deduce the return type if there is no trailing
return.
If no trailing return is given, then no return type would have been
specified, and a compiler error would be thrown (No return type specified).
In the case of the trailing return being "auto", it should be equivalent to
using the auto without a trailing return (to allow for consistent code
style).
The keyword would add additional specificity to the language, by allowing
programmers to better express intention.
examples:
auto get42(){ return 42; } //
returns 42 as an int (possibly unintended return type)
<keyword> get42(){ return 42; } // compiler error, no
return type specified
<keyword> get42()->double { return 42; } // returns 42 as a
double (intended)
<keyword> get42()->auto { return 42; } // returns 42 as an int
(auto return type behavior intended)
This is useful in preventing the following:
auto get42()->double { return 42; } // Intended: returns 42
as a double
auto get42() { return 42; } // Unintended:
returns 42 as an int
In this case, the error is that the programmer intended to write a function
with a trailing return, but forgot the trailing return.
Everything could work fine, or unintended behavior could occur in the
program somewhere due to the different type.
The source of the unintended behavior could also be difficult to locate,
especially if the auto keyword is overused.
A similar issue can also be introduced in the case of a bad refactor, if
the return type of an auto function is unintentionally changed.
The keyword would prevent issues like this by catching such a scenario at
compile time using additional specificity.
Thus the case of a programmer unintentionally forgetting to specify a
trailing return type, can be caught at compile time, and remove a source of
difficult to locate errors.
It also increases code readability, by better expressing programmer intent.
Hopefully I've shown that such a keyword is useful, and there is just the
question of naming.
The two keywords I've thought of are "trailing" and the ever controversal
"func".
My preference is towards "func", since I think it makes code more readable.
example: func get42()->double() { return 42; }
Unfortunately I am not sure if it would cause any name conflict issues
given the given the prevalence of the abbreviation.
It could also possibly conflict with possible future uses of func.
needs to be addressed, and would like some feedback regarding the issue and
this proposed solution.
I also did not see this anywhere else, but if it is redundant, please let
me know.
*Currently the auto keyword is required to use a trailing return (except
with lambda functions).*
*However, auto can also be used without a trailing return to auto-deduce
the return type.*
*This can lead to errors if a trailing return is unintentionally forgotten,
which could then cause difficult to locate unintended behavior.*
*I'd like to discuss a keyword that required that the function return type
should be specified though a trailing return.*
The keyword would take on a subset of the auto keyword's behavior. Similar
to the auto keyword, it would look for the trailing return.
However, it would not auto deduce the return type if there is no trailing
return.
If no trailing return is given, then no return type would have been
specified, and a compiler error would be thrown (No return type specified).
In the case of the trailing return being "auto", it should be equivalent to
using the auto without a trailing return (to allow for consistent code
style).
The keyword would add additional specificity to the language, by allowing
programmers to better express intention.
examples:
auto get42(){ return 42; } //
returns 42 as an int (possibly unintended return type)
<keyword> get42(){ return 42; } // compiler error, no
return type specified
<keyword> get42()->double { return 42; } // returns 42 as a
double (intended)
<keyword> get42()->auto { return 42; } // returns 42 as an int
(auto return type behavior intended)
This is useful in preventing the following:
auto get42()->double { return 42; } // Intended: returns 42
as a double
auto get42() { return 42; } // Unintended:
returns 42 as an int
In this case, the error is that the programmer intended to write a function
with a trailing return, but forgot the trailing return.
Everything could work fine, or unintended behavior could occur in the
program somewhere due to the different type.
The source of the unintended behavior could also be difficult to locate,
especially if the auto keyword is overused.
A similar issue can also be introduced in the case of a bad refactor, if
the return type of an auto function is unintentionally changed.
The keyword would prevent issues like this by catching such a scenario at
compile time using additional specificity.
Thus the case of a programmer unintentionally forgetting to specify a
trailing return type, can be caught at compile time, and remove a source of
difficult to locate errors.
It also increases code readability, by better expressing programmer intent.
Hopefully I've shown that such a keyword is useful, and there is just the
question of naming.
The two keywords I've thought of are "trailing" and the ever controversal
"func".
My preference is towards "func", since I think it makes code more readable.
example: func get42()->double() { return 42; }
Unfortunately I am not sure if it would cause any name conflict issues
given the given the prevalence of the abbreviation.
It could also possibly conflict with possible future uses of func.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/41781a83-d5ed-46d3-a936-da2416158846%40isocpp.org.
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/41781a83-d5ed-46d3-a936-da2416158846%40isocpp.org.