Smooth transition to D2 for Tango users?

Denis Koroskin 2korden at gmail.com
Sat Sep 20 04:04:27 PDT 2008


On Sat, 20 Sep 2008 14:04:08 +0400, Bruce Adams  
<tortoise_74 at yeah.who.co.uk> wrote:

> On Thu, 18 Sep 2008 03:43:22 +0100, Jason House  
> <jason.james.house at gmail.com> wrote:
>
>> Denis Koroskin Wrote:
>>
>>> On Wed, 17 Sep 2008 18:31:02 +0400, Jason House
>>> <jason.james.house at gmail.com> wrote:
>>>
>>> > I'd like to see a smooth transition for Tango, not just the users! I
>>> > made several posts on the topic. The latest was titled "forward
>>> > compatibility" -- Making the D1 compiler tolerant of code that looks
>>> > like D2, but not adding new functionality...
>>> >
>>>
>>> Please, Walter, comment on this!
>>> Shall we put the request into bugzilla?
>>
>> My last bugzilla request still doesn't have a response... Walter has  
>> said before that he doesn't like raining on people's parade, so maybe  
>> his silence should be assumed to be a rejection?
>
> The thing is what you are asking for is a major change to the D1.0 spec.
> D1.0 is frozen. Bug fixes (to the spec) are permitted but major additions
> are not. Moreoever this addition does not add any functionality. So  
> while it
> may seem like a sensible thing to do from a pragmatic programmer's point  
> of view
>  from a language design point of view its very silly indeed.
>

Why is it? All we ask is to make the versioning *slightly* smarter and not  
raise an error in the following code:

class Foo
{
   version(D_Version2) {
     int bar() const { return 42; }
   } else {
     int bar() { return 42; }
   }
}

Okay, why is D_Version2 introduced in the first place? Isn't it supposed  
to be used to check against D compiler version? Yes, it is. Why do I what  
to check compiler version in my source code? Because I want my source code  
to be compilable with both DMD1 *and* DMD2.

I want to write a library and I want it so be useful to as much people as  
possible. What language should I write it in? D1 or D2?

Well, almost everyone is using D1, that's why D2 is not an option.

D2 is released *more that a year* ago but is still not popular. Do you  
think no one wants to use it? No, that's not the case. Lots of people  
still using D1 just because there is no way to write code so that it is  
compilable with both versions. I *do* want to use it but I can't. And I  
won't do any serious programming in D2 until this issue is resolved. And  
if it won't get resolved... well, I'll most probably quit the community.

It is too much restricting and frustrating. Thanks for listening.

> You need to find a difficult way to tackle the problem.
> Its not a simple as the vanilla case of wanting one code base to support  
> two
> dialects of the same language (e.g. two difficult non standard C++  
> compilers before
> we had a standard). As I understand it its the const system in D2.0  
> makes it more
> complicated. People have posted clever suggestions using templates but  
> these make
> both the D1 and D2 code ugly.
> How about using source code transformation instead. Generate D1.0  
> compliant code from
> D2.0 code (with a minimum number of version blocks for the ugly stuff).  
> Kind of a
> DFront if you like. It needs specing in more detail but here are some  
> ideas to ponder:
>
> * strip const's and invariants from the source in appropriate contexts
> - const is legal/sensible in some places in D1.0  which is why sed -e  
> s/const//g won't be enough
> - ideally use a D1.0 parser (you can only do simple source code  
> transformations without it - maybe that would be enough)
>
> * use source code annotations specific to your Doneificator program (for  
> the bits a brain dead translator can't handle alone)
> - @deletemethod   - remove the method entirely from the translation
> - @noconst        - remove const from the following line / block of code
> - @keepconst      - do not remove const from the following line / block  
> of code
>
> Have a configure script which checks which versions of the compiler you  
> have available.
> For library developers the build system would build both variants in  
> different sub-directories
>
> source/
>     foo.d    (annotated D2.0)
>     v1/
>        foo.d   - D1.0 variant
>     V2/
>        foo.d   - D2.0 variant
>
> Put the clever stuff into your makefile:
>
> V1/foo.d: foo.d
>      dtrans --toD1 $< $@
>
> V2/foo.d: foo.d
>      dtrans --toD2 $< $@
>
> or
>
> DIALECT=--toD1
>
> foo.o: foo.d
>      dtrans $(DIALECT) $< $@
>      dmd $(DFLAGS) ...
>
> You have have your configure script set your DIALECT appropriately to  
> your environment and ensure your
> DFLAGS includes the right version setting for the bits 'dtrans' can't  
> handle.
>
> Having to do this sort of is why having a build system means more than  
> just having an IDE with a half arsed notion of projects
> (I'm talking to you windows VC++ :)
>
> If you do need to write such a beast it would probably fit well with one  
> of the build tools like DSSS
> but it should be standalone so everyone that care's can benefit.
>
> Regards,
>
> Bruce.
>

No-no-no, I won't read this. That's a no-go (for me, at least). I would  
write it C/C++ with its preprocessor instead.



More information about the Digitalmars-d mailing list