[OT] Modules dropped out of C++17

weaselcat via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 9 02:23:14 PDT 2015


On Tuesday, 9 June 2015 at 09:16:40 UTC, weaselcat wrote:
> 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.

also, I wonder what the assembly output using the ranges proposal 
looks like. I often see my range code boiled down to a few vector 
ops by GDC and LDC, but AFAIK a lot of effort has gone into 
making ranges as efficient as possible.


More information about the Digitalmars-d mailing list