Re: [boost] Variant2 review

Subject: Re: [boost] Variant2 review
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-04-09 01:40:15

On 4/8/19 6:08 PM, Gavin Lambert via Boost wrote:
> On 9/04/2019 11:13, Niall Douglas wrote:
>>> Why do you bother with the #ifdef NDEBUG ?
>>
>> It signifies "this is important for the final release binary" i.e.
>> please ask one of the tech leadership if you break this.
>>
>> It has no technical meaning. But it is *very* effective at worrying 
>> people.
> 
> Its technical meaning is that during development in debug builds (which 
> presumably people should be using most of the time in order to verify 
> runtime asserts and other things like debug iterators and debug heaps), 
> all of these asserts are disabled, so people don't discover that they 
> did something wrong at the time that they broke it, which makes it 
> harder to discover what they broke.+1
> 
> So it seems like an odd choice, unless something about a debug build 
> makes the assertion untrue (eg. debug components changing sizeof).
> 
> Why not use #ifndef JUNIOR_DEVS_DONT_TOUCH or something similarly never 
> defined (and so never disabling the check) but expressing your real intent?
-1

First of all I'm with Naill in using static_assert alot.

But I come at it from a different place.  A big concern of mine is the 
explicit specification of type requirements.  This has now been subsumed 
in C++ as "concepts".  Ideally, I like to see the type requirements as 
explicitly list for each type in the documentation and mirrored in the 
code.  It might seem redundant, but it's not.  One is the interface 
design and the other is the implementation.  using static_assert for 
this purpose is a perfect match.  In my opinion - C++ concepts as 
specified for C++20 are superfluous.

Short version:

a) I think you're doing it basically right
b) It's a mistake to characterize this iast "protection against other 
developers. Actually it could be considered offensive to other 
developers.  We all need to do our part for creating a safe space for 
those other developers.
c) It's better to see it as using the compiler to explicity enforce type 
requirements in order to get correct code.

Robert Ramey.