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

Rolf Eike Beer eike at sf-mail.de
Tue Nov 18 13:51:18 EST 2014


Am Dienstag, 18. November 2014, 12:31:15 schrieb Ben Boeckel:
> 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.

continue() inside a function, but not inside a loop inside this function, 
should just be a hard error. Everything else is insane. And if it would be my 
decision I would just fix break() to behave the same, as everything else is 
just nonsense. It did not serve any useful purpose until now, so everyone 
could just remove that command from the function without losing anything. 
Noone could have ever assumed this to work, it did not do anything, so just 
kill it.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20141118/56383a05/attachment-0001.sig>


More information about the cmake-developers mailing list