[cmake-developers] [PATCH v5 0/4] Add continue keyword

[David Cole]

Putting continue, break or return inside of a macro definition is a
practice that should itself be discouraged...

(I know, people will probably still have cases of it, but it doesn't
seem like that's what any sane person would label a good practice, let
alone a best practice...)


On Tue, Nov 18, 2014 at 12:31 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Tue, Nov 18, 2014 at 18:06:30 +0100, Gregor Jasny wrote:
>> On 18/11/14 17:19, Ben Boeckel wrote:
>> > I wonder if we should
>> > fix anything about it and if so, make continue behave in an analogous
>> > way
>>
>> You want to make continue() bug compatible to break()?
>
> There are two parts here:
>
>   1) is there something wrong with the break() example (looking closer
>      at CMP0055 shows that, yes, there is)?
>   2) if so, do we make continue() act like it before or while fixing
>      break()?
>
> My concern is that with CMP0055 as-is, there is a case where continue()
> works as break() *should* but break() is set to an OLD policy and now
> they can have completely different semantics. If we decide that the
> example *does* show a problem, I'd like *one* policy for continue() and
> break() at the same time. Maybe it's not an issue because continue() is
> a completely new command and already basically moves you up to requiring
> 3.2 anyways in which case the mix-and-match behavior is only a problem
> with an explicit-OLD policy setting.
>
>> So the break in the macro worked, the break in the function got ignored.
>> This is expected behavior. The macro currently does not form an own
>> scope. Also variables set inside escape into the calling scope.
>>
>> The function forms an own scope (due to the Push/PopScope call).
>>
>> I think it is sane behavior that a macro does not form a scope / loop
>> context behavior. Or do you read macro like "macro function"?
>
> I guess I should have been more clear: the behavior exhibited is what I
> expected given my experience with macros and functions. It's more of a
> "do we fix it?".
>
>> > without any error messages (e.g., about using break() outside a
>>
>> This is because CMP0055 defaults to OLD here. If you add
>> "cmake_policy(SET CMP0055 NEW)" here you'll get a nice error.
>
> I think that this and the argument rule should be separate policies
> (removing arguments is easy; refactoring out a now-unallowed behavior
> might be harder depending on how deep down a macro calls break()).
>
>> > loop…which doesn't seem to happen anyways, so maybe this is moot). I
>> > don't see any existing tests about break inside of a function or macro
>> > having an effect on the caller's logic.
>>
>> What do you mean with 'effect' here?
>
> Calling a macro mutates your control flow (e.g., calling return()) in
> ways functions can't (and there's no distinction between macros and
> functions at the callsite).
>
> --Ben
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers