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.
