Moving towards D2 2.061 (and D1 1.076)

[Leandro Lucarella]

On Friday, 14 December 2012 at 03:40:05 UTC, Jonathan M Davis 
wrote:
> On Thursday, December 13, 2012 22:19:18 Andrei Alexandrescu 
> wrote:
>> On 12/13/12 8:55 PM, kenji hara wrote:
>> > I think we should have -future/-f switch and @future 
>> > attribute.
>> > It is a rough idea, but seems a required compiler feature.
>> > 
>> > Kenji Hara
>> 
>> That sounds interesting.
>
> I believe that python has something similar.

It does, but in Python they are only for breaking changes (for 
example when a new keyword is added, first you have to use form 
__future__import feature). Is kind of the reverse of deprecated. 
Also __future__ in Python is not really for experimental 
features, is for final ones, and present only to easy the 
migration (again, same as deprecated).

If the idea is to enable experimental features, I would name this 
-experimental rather than -future, which makes much clearer that 
you're on your own if you use that flag.

>> Regarding attributes, a simple solution is to release it but 
>> without
>> official documentation. We place the documentation in a 
>> /unstable/
>> directory of the website, distinct from the central mainstream
>> documentation.
>> 
>> People who already started or want to start using attributes 
>> understand
>> there are instabilities associated with them. Existing code is
>> unaffected, only certain programs that are technically invalid 
>> will
>> actually compile and run.
>> 
>> Works?

Only if you don't set this new experimental features in stone if 
some company have the crazy idea of start using it ;-)

> Yes. And attributes may not actually need much more work, but 
> adding new,
> essentially untested features into the language and releasing 
> them doesn't
> jive well with the recent push to stabilize and avoid breaking 
> any code,
> because such features will frequently need changes which will 
> break code.
> Hopefully, the adjustments to the release process that are 
> being discussed
> will fix this sort of problem long term, but it comes across 
> like Walter is
> willing to throw new features in but then generally refuses to 
> change things
> which break code, which risks us being stuck with features that 
> aren't quite
> what they could be or should be. The situation with UDAs 
> definitely highlights
> the need to adjust our release process.

Yes, to be honest, I don't think adding experimental features to 
what is supposed to be a stable compiler is a great idea. I think 
the best option is to add an experimental branch and add new 
features there. Having a nightly snapshot build of this 
experimental branch should be enough to encourage people to play 
with it making extremely clear that there are no warranties about 
the stability of that compiler, or on the continuation of new 
features there.