-Xfuture & -Xexperimental

I'm afraid the only way I know of is to grep the compiler source for either settings.Xexperimental.value, settings.future.value
From a quick inspection, it seems the only thing that actually (mostly) works is dependent method types, which allow you to write, e.g.:
def reallyTheIdentity(x: Any): x.type = x
adriaan
On Sun, Oct 11, 2009 at 2:07 AM, Daniel Mahler <dmahler@gmail.com> wrote:

Is there a simple way to find out what  -Xfuture & -Xexperimental
actually enable for any given release/snapshot?

thanks
Daniel


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Wed, Oct 14, 2009 at 2:29 AM, Adriaan Moors
wrote:
> I'm afraid the only way I know of is to grep the compiler source for
> either settings.Xexperimental.value, settings.future.value
> From a quick inspection, it seems the only thing that actually (mostly)
> works is dependent method types, which allow you to write, e.g.:
> def reallyTheIdentity(x: Any): x.type = x

I would really like to use this facility in everyday Scala code.

What are the criteria for promoting this from experimental to regular Scala?

> On Sun, Oct 11, 2009 at 2:07 AM, Daniel Mahler wrote:
>> Is there a simple way to find out what  -Xfuture & -Xexperimental
>> actually enable for any given release/snapshot?

IMHO there really ought to be. If a feature is too speculative to
identify and document, perhaps it belongs in a branch rather than
trunk?

-Ben

On Wed, Oct 14, 2009 at 1:06 AM, Ben Hutchison <ben@playscapegames.com> wrote:

On Wed, Oct 14, 2009 at 2:29 AM, Adriaan Moors
<adriaan.moors@cs.kuleuven.be> wrote:
> I'm afraid the only way I know of is to grep the compiler source for
> either settings.Xexperimental.value, settings.future.value
> From a quick inspection, it seems the only thing that actually (mostly)
> works is dependent method types, which allow you to write, e.g.:
> def reallyTheIdentity(x: Any): x.type = x

I would really like to use this facility in everyday Scala code.

What are the criteria for promoting this from experimental to regular Scala?

Martin (or someone else who knows the type checker well enough...) having time to implement and test it fully. Obviously I can't comment on a time frame for that, although I would [expect/hope for] it to land somewhere in a 2.8.x release near you. 
adriaan

On Wed, Oct 14, 2009 at 01:19, Adriaan Moors <adriaan.moors@cs.kuleuven.be> wrote:

On Wed, Oct 14, 2009 at 1:06 AM, Ben Hutchison <ben@playscapegames.com> wrote:

On Wed, Oct 14, 2009 at 2:29 AM, Adriaan Moors
<adriaan.moors@cs.kuleuven.be> wrote:
> I'm afraid the only way I know of is to grep the compiler source for
> either settings.Xexperimental.value, settings.future.value
> From a quick inspection, it seems the only thing that actually (mostly)
> works is dependent method types, which allow you to write, e.g.:
> def reallyTheIdentity(x: Any): x.type = x

I would really like to use this facility in everyday Scala code.

What are the criteria for promoting this from experimental to regular Scala?

Martin (or someone else who knows the type checker well enough...) having time to implement and test it fully. Obviously I can't comment on a time frame for that, although I would [expect/hope for] it to land somewhere in a 2.8.x release near you. 

I think the implementation should be re-worked.

The current implementation uses a special type called `DeBruijnIndex` because
back when it was done, a method type had the form
  MethodType(args: List[Type], res: Type)

Since 2.8.0, with named arguments, method types now are
  MethodType(args: List[Symbol], res: Type)
so the parameter symbols are available through the type. This means that
we no longer need the DeBruijnIndicies.

One thing that should be investigated: I guess that similar to type parameter
symbols, there will be two symbols for each parameter, the one in the type
and the one used to type-check the method body (aka `skolemize` / `deSkolemize`).
This already happens now I think (parameter symbols are cloned), but there's
no way to get from one to the other.

Cheers: Lukas