On 28/06/2019 13:16, Magnus Fromreide via Std-Proposals wrote:
> On Thu, Jun 27, 2019 at 08:17:52PM +0100, Jake Arkinstall via Std-Proposals wrote:
>> To be honest, I'd prefer to see mandatory braces for all control statements.
> There arre cases, especially where macros are concerned, where an "open scope"
> (one without braces) is extremely useful.
>
> Consider the classic one:
>
> #define LOG if (!logging_enabled()) ; else get_log_stream()
>
> which is used like
>
> LOG << "Kilroy was here";

shouldn't we be getting rid of the pre-processor not perpetuating it


>> My main preference would be neither of these things happening
> :-)
>
> /MF
>
>> - 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

-- 
    .~.     In my life God comes first....
    /V\         but Linux is pretty high after that :-D
   /( )\    Francis (Grizzly) Smit
   ^^-^^    http://www.smit.id.au/