Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-08 16:10:55
On 11/8/2012 6:23 AM, Dave Abrahams wrote:
> on Mon Nov 05 2012, Paul Mensonides <pmenso57-AT-comcast.net> wrote:
>> For any extension that is just syntactic sugar or not desperately
>> required (as hardware vectorization may be), yes. Their existence is
>> damaging in the long term.
> Wow, that doesn't sound good to me. We already have trouble
> establishing "existing practice" for new features. What you're
> suggesting would be a serious problem for the process, unless you only
> want to see major changes to the standard, and no new
> not-desperately-required-but-nice-to-have "cleanups" or "syntactic
> sugar." IMO those incremental improvements might be just as important
> as the big things.
If it starts and ends with the committee. For example, floating whether
an idea has merit, implementing it if it appears the path to
standardization is viable, gathering use experience, and then presenting
it for standardization. If it is rejected, remove it (i.e. allow code
to break that uses the experimental extension). If it is accepted as
is, great. If it is accepted with modifications, modify it to conform
(i.e. allow code to break that uses the experimental extension).
In many cases of current extensions, however, we have significant
existing practice in other languages. For example, one doesn't need an
implementation of "properties" as an extension to C++, one doesn't need
an implementation of an "interface" keyword, one doesn't need a
"finally" extension, one doesn't need an "event" extension, etc., etc.,
yet that hasn't stopped MS from implementing them (and a bunch of others).
Other implementers do this kind of thing also, but, AFAICT, none of them
are even in the ballbark of MS running roughshod over the language with
whatever they want.
It is one thing if an extension is implemented for possible future
standardization (and tweaked or removed pending the results of that)
with the intent to gain use experience. It is another when it is simply
some vendor deciding they like some feature, adding it, and then
promoting its use. That is an abuse of power that fractures the
language and destroys portability.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk