[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