[OT] Modules dropped out of C++17

[weaselcat via Digitalmars-d]

On Tuesday, 9 June 2015 at 08:57:58 UTC, Chris wrote:
> 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.
>


+1
the range library proposal is *ugly,* and the author did the best 
he could honestly.

on the topic of D advancing ahead of C++, I think language 
built-in tuples and pattern matching would be a good start : )