[OT] Modules dropped out of C++17

[Chris via Digitalmars-d]

On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote:
> On Monday, 8 June 2015 at 19:24:47 UTC, Walter Bright wrote:
>> On 6/8/2015 11:17 AM, Paulo Pinto wrote:
>>> Apparently modules have been pushed into a Technical 
>>> Specification, and won't be
>>> ready on time for inclusion into ANSI C++ 17.
>>>
>>> https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/
>>>
>>>
>>> So, here is another feature that D wins over C++.
>>
>> Looks like C++ is adopting ever more D features:
>>
>>
>> "proposed a syntax for declaring preconditions, 
>> postconditions, and invariants for a function in its interface 
>> (i.e. in its declaration), primarily for the purpose of static 
>> analysis and enabling compiler optimizations."
>>
>> "Bjarne presented the latest version of his proposal for 
>> automatically generating comparison operators for class types."
>>
>> "Unified call syntax. This proposal, by Bjarne, seeks to unify 
>> the member (x.f(y)) and non-member (f(x, y)) call syntaxes by 
>> allowing functions of either kind to be invoked by syntax of 
>> either kind."
>>
>> "A restricted form of static_if;"
>>
>> "Extending static_assert to allow taking for the error message 
>> not just a string literal, but any constant expression that 
>> can be converted to a string literal."
>>
>> "noexcept(auto), which basically means “deduce the 
>> noexcept-ness of this function from the noexcept-ness of the 
>> functions it calls." (This is essentially doing "nothrow" 
>> attribute inference.)
>>
>> "Eric Niebler came to that meeting with a detailed and well 
>> fleshed-out design for ranges in the standard library."

This is really funny. After years of ignoring or bashing and 
ridiculing D. Those who work with D know who useful these 
features are. They must have worked with it too ;)

> I see a problem that having those features in C++ will reduce 
> the desire from companies to adopt D.

Yes and no. In D these features have been carefully crafted to be 
part and parcel of the language (there are still some rough 
edges, but well). In C++ it's gonna be the usual "glue it on top 
of what we have and make complicated rules in order not interfere 
with legacy code". In short, it's gonna be a nightmare to use and 
people will stick to what they know, I think.

> At very least they should acknowledge all of you guys for the 
> ideas.

They would never do that.