These protracted debate over feature test macros always remind me of the sage 
words of the inventor of macros for C, Doug McIlroy (and the inventor of the 
field of Software Engineering):


Ø  Most #ifdef's and #if's memorialize failures of imagination

Ø  or care, often in the name of "portability".  Code is

Ø  NOT portable if it has to be rewritten according to the

Ø  conventions of each environment.  Ifdef expresses just such

Ø  rewriting, and in an egregious style: it inverts the

Ø  logical structure of a program, bringing the tweaks to

Ø  the top while fragmenting the real architecture.

Source:  https://www.mail-archive.com/[email protected]/msg00795.html

-- Gaby

From: Core <[email protected]> On Behalf Of Barry Revzin via Core
Sent: Monday, June 15, 2020 7:27 AM
To: Ville Voutilainen <[email protected]>
Cc: Barry Revzin <[email protected]>; Marek Polacek <[email protected]>; 
C++ Core Language Working Group <[email protected]>; [email protected]
Subject: Re: [isocpp-core] [SG10] Feature-test macro for ADL calls with 
template arguments?



On Tue, Jun 9, 2020 at 10:18 AM Ville Voutilainen 
<[email protected]<mailto:[email protected]>> wrote:
On Tue, 9 Jun 2020 at 18:15, Barry Revzin 
<[email protected]<mailto:[email protected]>> wrote:
>> I find it rather plausible that a simplicity-seeking programmer will
>> just not provide a structured-bindings
>> interface that he also wants to allow calling via ADL outside
>> structured bindings when an implementation
>> of P0846 is not available.
> I'm having trouble parsing this sentence. Is the claim that being unable to 
> write get<0>(e) is a reason for somebody to avoid opting into structured 
> bindings?

The claim is that it's plausible to not provide a get<> if it can't be
ADL-called without additional incantations.
Choosing to do so will also not-enable support for structured bindings.

That seems like a surprising choice to me... but conditionally providing 
functionality is basically what we have feature test macros for, so I guess it 
makes sense.

Barry
-- 
SG10 mailing list
[email protected]
https://lists.isocpp.org/mailman/listinfo.cgi/sg10

Reply via email to