User talk:D41D8CD98F

Thanks for fixing a bug in the mini-example for template argument deduction from an overload set! In retrospect, it was pretty dumb error. --Cubbi (talk) 08:43, 20 April 2015 (PDT)
 * I also made a mistake. I thought P means "the parameter type". Now I realize that P actually means "type to be deduced".--D41D8CD98F (talk)

C17 DRs
regarding your question Should the change made by C17 be treated as DR (and thus applied retroactively to C11)
 * I'd say yes for most of them, but the ATOMIC_VAR_INIT change is considered to be more significant, at least by the WG14 member who posted that comment to SO. --Cubbi (talk) 11:58, 12 December 2017 (PST)
 * I see. Thanks for your response. --D41D8CD98F (talk) 00:48, 13 December 2017 (PST)

constexpr rollback
The change you rolled back had a purpose. constexpr, when applied to a variable, is not "possibly" anything; it is very definitely and without question a constant expression (or it's ill-formed). So the form of the statement you restored is misleading. Korval (talk) 20:17, 6 January 2020 (PST)


 * I think saying a constexpr variable "is a constant expression" is even less correct. It depends on how the variable is used:


 * (cpp/language/constant_expression has a similar example.)
 * Moreover, the constexpr variable might have a mutable member. Such variable can be used in constant expressions (as long as the mutable member is not accessed), but IMO it doesn't make sense to say that the variable, as a whole, is a constant expression. --D41D8CD98F (talk) 21:47, 6 January 2020 (PST)

typename revert
Hi, I see you reverted my change to typename. I see now that using typename inside casts only works on MSVC, I apologize, I think I misunderstood the relaxed typename rules described in Vandevoorde's book. Without more context though, I could only guess at what you thought was wrong; it would help if you could be more specific next time. For example, in [temp.res] the standard says "A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename." I interpret this as the typename hinting the compiler that something is a typename if name lookup fails.

Jeffythedragonslayer (talk) 20:01, 17 May 2020 (PDT)


 * Sorry. I thought that you meant is valid, so I thought the problem is too obvious to be noted.
 * The usage you described has been mentioned in the second and third bullets in cpp/keyword/typename, but the wording can probably be improved. --D41D8CD98F (talk) 23:46, 17 May 2020 (PDT)


 * Yes, that was exactly what I thought was valid. I'll test on more compilers next time.

Jeffythedragonslayer (talk) 08:10, 18 May 2020 (PDT)

On static lambdas
Considering "static lambdas" from :

Shouldn't the next-gen C++ provide a static lambda as a means of generating a class with static fields!? The "source" of types and initializes for such static fields would obviously be the capture-list.

This approach enhances utility of static lambdas, whereas the restriction looks somewhat artificial.

Promoting this we would have these simple rules:
 * non-static lambda &rarr; non-static data members,
 * static lambda &rarr; static data members.

Benefits:
 * static ClosureType::operator has natural access to static data members;
 * static data members (naturally) hold their state after lambda-object is out of scope (destroyed). This is useful in scenarios, when the static lambda-expression is defined in a function that is being invoked several times, so the "state" of the lambda is "preserved" between calls.

One possible usage pseudo-example:

This is only a raw idea, maybe not viable. --Space Mission (talk) 16:11, 8 October 2022 (PDT)