D is an evolving language that does not restrict itself by requiring backwards compatibility. Instead I propose that D adopt forward compatibility...

Specifically, allow D1 code to accept D2 code without doing extra functionality. In D1, his would allow defining constants to be declared with either const or invariant, object invariants to allow parenthesis,  and ignoring transitive const elements of type declarations.

The goal is to not change the behavior of existing D1 code, but to accept previously invalid D1 code. This should make the job of maintaining a dual code base much easier.

I'm all for anything that makes D1, or the combo of D1 & D2, more usable.

--bb

On Fri, Sep 5, 2008 at 2:57 PM, Jason House <jason.james.house@gmail.com> wrote:
> D is an evolving language that does not restrict itself by requiring backwards compatibility. Instead I propose that D adopt forward compatibility...
>
> Specifically, allow D1 code to accept D2 code without doing extra functionality. In D1, his would allow defining constants to be declared with either const or invariant, object invariants to allow parenthesis,  and ignoring transitive const elements of type declarations.
>
> The goal is to not change the behavior of existing D1 code, but to accept previously invalid D1 code. This should make the job of maintaining a dual code base much easier.
>

On 2008-09-06 03:00:37 +0200, "Bill Baxter" <wbaxter@gmail.com> said:

> I'm all for anything that makes D1, or the combo of D1 & D2, more usable.
> 
> --bb
> 
> On Fri, Sep 5, 2008 at 2:57 PM, Jason House <jason.james.house@gmail.com> wrote:
>> D is an evolving language that does not restrict itself by requiring backwards compatibility. Instead I propose that D adopt forward compatibility...
>> 
>> Specifically, allow D1 code to accept D2 code without doing extra functionality. In D1, his would allow defining constants to be declared with either const or invariant, object invariants to allow parenthesis,  and ignoring transitive const elements of type declarations.
>> 
>> The goal is to not change the behavior of existing D1 code, but to accept previously invalid D1 code. This should make the job of maintaining a dual code base much easier.

I thnk that it would be very good for tango (and phobos?), as it would mean that a big part of the code (and bugfixes,...) might be shared between D1.0 and D2.0.
As these libraries will need to be supported in D1.0 for more time (as long a important projects use D1.0).

For smaller things... well the developer will probably focus just on the language they are using, which means the one of the base library.

Easing the transition is to D2.0 for big projects is worthwhile I think.

Fawzi

On Fri, 05 Sep 2008 09:57:40 +0400, Jason House <jason.james.house@gmail.com> wrote:

> D is an evolving language that does not restrict itself by requiring backwards compatibility. Instead I propose that D adopt forward compatibility...
>
> Specifically, allow D1 code to accept D2 code without doing extra functionality. In D1, his would allow defining constants to be declared with either const or invariant, object invariants to allow parenthesis,  and ignoring transitive const elements of type declarations.
>
> The goal is to not change the behavior of existing D1 code, but to accept previously invalid D1 code. This should make the job of maintaining a dual code base much easier.

I came up with the following constness solution:

First, define a Const!(T) template as follows:

// dconst.d
version (D_Version2) {
    public import dconst2;
} else {
    public import dconst1;
}

//dconst1.d
template Const(T)
{
    alias const T Const;
}

//dconst2.d
template Const(T)
{
    alias const(T) Const;
}

Now you can import dconst.d and use the Const!(T) template in your code do define constant objects:

import dconst;

void foo(Const!(Bar) bar)
{
    // ...
}

D1 will ignore constness while D2 will preserve and respect it.

Next, you should add const methods into your classes:

class Node
{
    Node next() {
        return _next;
    }

version (D_Version2) {         // You have to duplicate the code
    const Const!(Node) next()  // when return a reference object in
    {                          // D2 anyway, so that's not a big deal.
        return _next;
    }
}

    void next(Node value) {
        _next = value;
    }

version (D_Version2) {        // However, you don't have to for void and
    const int value() {       // value types, and this is quite a pain now
        return _value;        // (especially for long function bodies).
    }
} else {
    int value() {
        return _value;
    }
}

    void value(int value) {
        _value = value;
    }

    private int _value;
    private Node _next;
}

// Test case:
void test(Const!(Node) node)
{
    Const!(Node) nextNode = node.next;
    if (nextNode !is null) {
        writefln(nextNode.value);
    } else {
        writefln(node.value);
    }
}

So here is my suggestion:
1) there should be something like Const template in Phobos/Tango for D1/D2 compatibility. It is very simple yet clean and it is as easy to write Const!(T) as const(T).

2) D1 should swallow and ignore const modifier for member functions so that there would be no need for body duplication:

// Same for D1 *and* D2 (although meaning is slightly different)
// no need for version (D_Version2) { ... } else { ... } anymore

class Node {
    int value() const {
        return _value;
    }
}

This would allow much easier D1/D2 migration without massive language changes.

What do you think?

A quote wrote some time ago:

"Sean Kelly" wrote
> Bill Baxter wrote:
>> Sean Kelly wrote:
>>> dsimcha wrote:
>>>> On another note, anyone have any idea when/if Tango for D2, andTangobos for Tangofor D2, will be available?  There are things I like and dislike aboutboth Tangoand Phobos, and I really wish I could mix and match modules from themwithoutgiving up my D2 features.  For example, I like Phobos's much simpler IOAPI, less"OO everywhere" look and feel and "simple operations should be simple"mentality,but I like Tango's extra math and threading stuff and richer featureset ingeneral.  Also, I've written a decent amount of Phobos code that Idon't feel likeporting.
>>> There's no timeframe for D2 support at the moment.  I may look into atleast having the runtime be cross-compatible, but porting the user codewould require changes in structure / coding strategy that I can't seeanyone wanting to make.
>> It seems to me that some people do actually like D2 and aren't usingTango precisely because there's no D2 support.  So who knows, maybeyou'll find there's a new crop of D2/Tango volunteers that show up oncethe ball gets rolling.  Steven S. for one, perhaps.
> Yup.  There has been enough interest that I think it's worth getting theruntime working at least.  The only real obstacle to that right now istime.  The runtime uses the standard C, Posix, and Win32 packages forvarious things and none of these are D2 compatible at the moment.  So thesticking point is really that I need to find the time to go through thestandard C and Posix specs and add "in" to all the function parametersthat are const in the C APIs.  I should have left /*const*/ as aplaceholder when I created the modules but... oh well.  Live and learn.

Not /*const*/ but Const!()

Denis Koroskin wrote:

> On Fri, 05 Sep 2008 09:57:40 +0400, Jason House <jason.james.house@gmail.com> wrote:
> 
>> D is an evolving language that does not restrict itself by requiring backwards compatibility. Instead I propose that D adopt forward compatibility...
>>
>> Specifically, allow D1 code to accept D2 code without doing extra functionality. In D1, his would allow defining constants to be declared with either const or invariant, object invariants to allow parenthesis, and ignoring transitive const elements of type declarations.
>>
>> The goal is to not change the behavior of existing D1 code, but to accept previously invalid D1 code. This should make the job of maintaining a dual code base much easier.
> 
> I came up with the following constness solution:
> 
> First, define a Const!(T) template as follows:
> 
> ...
> 
> This would allow much easier D1/D2 migration without massive language changes.
> 
> What do you think?

I was worried that making a D1 compiler accept const in types declarations would be a killer of the forward compatibility idea.  I think what you propose for const type handling is a reasonable compromise.  It'd be easy enough to write a Const!(T) and Invariant!(T) template.

I like how all the response to my proposal has been positive.  Sadly, it can't go anywhere unless Walter likes the idea and he has yet to respond.