[OT] Modules dropped out of C++17
weaselcat via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jun 9 02:16:39 PDT 2015
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 : )
More information about the Digitalmars-d
mailing list