I would not be opposed to allowing something in the lines of

int /* or auto */ getFoo(...) -> /* some expression */;

Which would be logically equivalent to

int /* or auto */ getFoo(...) { return /* some expression */; }

And applying that same idea to lambdas, to make one liners more convenient:

[] -> /* some expression */
[](int i) -> i % 2 == 0
[i](int j) -> i == j

On Thu, Jun 27, 2019, 15:18 Jake Arkinstall via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> To be honest, I'd prefer to see mandatory braces for all control
> statements.
>
> My main preference would be neither of these things happening - but to me,
> a change that makes code more uniform is preferable over a code that makes
> errors easier to make for the sake of a couple of bytes.
>
> On Thu, 27 Jun 2019, 20:11 Tom Honermann via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> void f1() // Oops, forgot ;
>> void f2(); // Now a local declaration in the definition of f1().
>>
>> Tom.
>>
>> On 6/27/19 12:29 PM, Kyle Knoepfel via Std-Proposals wrote:
>> > Here’s an idea I’ve been thinking about a lot regarding functions
>> composed of a single statement, and I’d like your thoughts.
>> >
>> > Consider the following function (and associated enumeration):
>> >
>> > enum class person {alice, bob, david};
>> > std::string_view greet(person const p)
>> > {
>> > switch(p) {
>> > case person::alice: return “Hello Alice.”sv;
>> > case person::bob: return “What’s up Bob?”sv;
>> > case person::david: return “(Avoid eye contact)”sv;
>> > }
>> > }
>> >
>> > In such a case, where there is no function-local state, I argue that
>> the outer braces should be unnecessary:
>> >
>> > std::string_view greet(person const p)
>> > switch(p) {
>> > case person::alice: return “Hello Alice.”sv;
>> > case person::bob: return “What’s up Bob?”sv;
>> > case person::david: return “(Avoid eye contact)”sv;
>> > }
>> >
>> > Of course, once someone wants to introduce function-local variables
>> that are otherwise not contained by the statement in the function, then
>> braces are required:
>> >
>> > std::string greet(person const p)
>> > std::string const salutation{“Hi “}; // Error! Two statements in
>> non-braced function definition.
>> > switch(p) {
>> > case person::alice: return salutation + "Alice.”;
>> > case person::bob: return salutation + “Bob.”;
>> > case person::david: return “(Avoid eye contact)”;
>> > }
>> >
>> > I also run into functions that are defined like:
>> >
>> > void print_results(std::vector<Result> const& results)
>> > {
>> > for (auto const& res : results) {
>> > std::cout << res << ‘\n’;
>> > }
>> > }
>> >
>> > An arguably better approach would be to do something like:
>> >
>> > for_all(results, [](auto const& res){ std::cout << res << ‘\n’; });
>> >
>> > but I occasionally run into situations where it may be more convenient
>> to keep the explicit for loop:
>> >
>> > void print_results(std::vector<Result> const& results)
>> > for (auto const& res : results) {
>> > std::cout << res << ‘\n’;
>> > }
>> >
>> > Or consider the handling of simple member functions:
>> >
>> > template <typename T>
>> > class my_dumb_pointer {
>> > T* ptr_;
>> > public:
>> > T* get() const noexcept { return ptr_; } // vs
>> > T* get() const noexcept return ptr_; // Simpler? Not sure.
>> > };
>> >
>> > Function definitions with empty bodies would still require braces.
>> >
>> > Does this idea seem worth fleshing out? How difficult would it be for
>> implementations to provide, if it was worthwhile?
>> >
>> > Thanks very much,
>> > Kyle Knoepfel
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>