www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.126

reply "Walter" <newshound digitalmars.com> writes:
Added inner classes.

http://www.digitalmars.com/d/changelog.html
Jun 07 2005
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Best. Release. Ever. I will be able to sleep well now : )
Jun 07 2005
prev sibling next sibling parent kris <fu bar.org> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Holy Moly ~ that is one phat release ...
Jun 07 2005
prev sibling next sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
It's looking great! Thans a lot!

"Walter" <newshound digitalmars.com> wrote in message 
news:d85vju$so2$1 digitaldaemon.com...
| Added inner classes.
|
| http://www.digitalmars.com/d/changelog.html
|
|
|
Jun 08 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Well done...I thought you'd been quiet for awhile ;-)

I especially like the way you are prepared to allow potentially 'dangerous'
behaviour and explain why it is so (re: Void Initializers). This shows that
D is willing to trust the advanced coder who knows what they are doing.

-- 
Derek
Melbourne, Australia
8/06/2005 5:36:00 PM
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:8hj4a6bljgap$.1jlptuycpjghd.dlg 40tude.net...

 Well done...I thought you'd been quiet for awhile ;-)


Thanks!


 I especially like the way you are prepared to allow potentially


'dangerous'

 behaviour and explain why it is so (re: Void Initializers). This shows


that

 D is willing to trust the advanced coder who knows what they are doing.


The idea is not to disallow such behavior, like Pascal and Java do, but to
make such practices obvious in the code and not the default. Potentially
'dangerous' behavior should be coded in on purpose, not inadvertently, and
should be identifiable with a visual inspection of the code.

The void initializer I think fills that role perfectly.
Jun 08 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d868t4$18rh$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message
 news:8hj4a6bljgap$.1jlptuycpjghd.dlg 40tude.net...

 Well done...I thought you'd been quiet for awhile ;-)


 Thanks!


 I especially like the way you are prepared to allow potentially


 'dangerous'

 behaviour and explain why it is so (re: Void Initializers). This shows


 that

 D is willing to trust the advanced coder who knows what they are doing.


 The idea is not to disallow such behavior, like Pascal and Java do, but to
 make such practices obvious in the code and not the default. Potentially
 'dangerous' behavior should be coded in on purpose, not inadvertently, and
 should be identifiable with a visual inspection of the code.


absolutely true, IMHO. As much code is compact and obvious as better
to visual inspect it and get an idea of what is going on - thus
to write reliable code. And this is why D is so attractible now.

Having said that and using "practices obvious in the code" motto
I am thinking about have a question:

Currently following:

const char[] s = "Hello";
    s[0] = 0;

compiles just fine.

What is l-value then in terms of D considering
that arrays are built-in in its type system?

I read history of D discussions about const's, got your and
your opponents points, etc.

I understand that it is too difficult
(read almost impossible to get fast and reliable compiler)
to cover current C++ const cases. And I agree that current
const system in C++ is overkill and is not
good at all as it contradicts with "practices obvious
in the code". Especially in complex class hierachies
and systems.

Considering that arrays are both values and references
then type system should include const content
accent modifier for them like:


                      // opIndexAssign etc. - immutable array.

                      // no opIndexAssign modifying its content.

Such solution don't need current const syntax redesign

also be made this way.




Andrew.
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d87fob$2dn0$1 digitaldaemon.com...

 Having said that and using "practices obvious in the code" motto
 I am thinking about have a question:

 Currently following:

 const char[] s = "Hello";
     s[0] = 0;

 compiles just fine.


It shouldn't. I just haven't gotten around to dealing with that.
Jun 08 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d87hn9$2fmi$3 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d87fob$2dn0$1 digitaldaemon.com...

 Having said that and using "practices obvious in the code" motto
 I am thinking about have a question:

 Currently following:

 const char[] s = "Hello";
     s[0] = 0;

 compiles just fine.


 It shouldn't. I just haven't gotten around to dealing with that.


Thanks for clarification.

Having implemented this I guess following should be
impossible too:
      "Hello"[0] = 0;
(now it compiles, and more interestingly, works just fine)

If you will implement this then it will effectively mean that type of
string constant will be something like:
      const static char[N]

Which will require that:

      char[] s = "hello";

will allocate new char array, in other words will be equivalent to

      char[] s = "hello".dup;

Am I right?

Andrew.
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d87k31$2iaq$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d87hn9$2fmi$3 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d87fob$2dn0$1 digitaldaemon.com...

 Having said that and using "practices obvious in the code" motto
 I am thinking about have a question:

 Currently following:

 const char[] s = "Hello";
     s[0] = 0;

 compiles just fine.


 It shouldn't. I just haven't gotten around to dealing with that.


 Thanks for clarification.

 Having implemented this I guess following should be
 impossible too:
       "Hello"[0] = 0;
 (now it compiles, and more interestingly, works just fine)

 If you will implement this then it will effectively mean that type of
 string constant will be something like:
       const static char[N]

 Which will require that:

       char[] s = "hello";

 will allocate new char array, in other words will be equivalent to

       char[] s = "hello".dup;

 Am I right?


No, what I plan to do is put string literals into a read-only section of
memory. Attempting to change it will result in a runtime fault.
Jun 08 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d87med$2l0t$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d87k31$2iaq$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d87hn9$2fmi$3 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d87fob$2dn0$1 digitaldaemon.com...

 Having said that and using "practices obvious in the code" motto
 I am thinking about have a question:

 Currently following:

 const char[] s = "Hello";
     s[0] = 0;

 compiles just fine.


 It shouldn't. I just haven't gotten around to dealing with that.


 Thanks for clarification.

 Having implemented this I guess following should be
 impossible too:
       "Hello"[0] = 0;
 (now it compiles, and more interestingly, works just fine)

 If you will implement this then it will effectively mean that type of
 string constant will be something like:
       const static char[N]

 Which will require that:

       char[] s = "hello";

 will allocate new char array, in other words will be equivalent to

       char[] s = "hello".dup;

 Am I right?


 No, what I plan to do is put string literals into a read-only section of
 memory. Attempting to change it will result in a runtime fault.


I see. So

char[] s = "Hello";
     s[0] = 0;

will compile fine, but will raise AV in runtime.....

Will it be possible to determine in runtime is it read-only
array or not without Access Violation Error?

Thanks,

Andrew.
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d87q98$2pam$1 digitaldaemon.com...

 No, what I plan to do is put string literals into a read-only section of
 memory. Attempting to change it will result in a runtime fault.


 I see. So

 char[] s = "Hello";
      s[0] = 0;

 will compile fine, but will raise AV in runtime.....

 Will it be possible to determine in runtime is it read-only
 array or not without Access Violation Error?


You could by looking at the s.ptr value and seeing if it is within the span
of a read-only section of data. One way of doing this is to put a try..catch
around an attempt to change it, and catch the AV.
Jun 08 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d87tgq$2s36$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d87q98$2pam$1 digitaldaemon.com...

 No, what I plan to do is put string literals into a read-only section 
 of
 memory. Attempting to change it will result in a runtime fault.


 I see. So

 char[] s = "Hello";
      s[0] = 0;

 will compile fine, but will raise AV in runtime.....

 Will it be possible to determine in runtime is it read-only
 array or not without Access Violation Error?


 You could by looking at the s.ptr value and seeing if it is within the 
 span
 of a read-only section of data. One way of doing this is to put a 
 try..catch
 around an attempt to change it, and catch the AV.


Thanks. Clear enough.

(And I'll be on my own to discover read-only adress ranges, right?
Rhetoric question. Don't need to answer.)

Andrew.
Jun 08 2005
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html



OMG, where's my jaw ? Great job, Walter !



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jun 08 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Could we please at least have an answer about these?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3173

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 08 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:


 Could we please at least have an answer about these?
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3173


David has fixed the GDC compiler (0.12) so that it outputs to stderr...
Probably since I was complaining about it breaking my -pipe builds :-)

Unfortunately that only goes for the *compiler* errors. The runtime
errors, such as uncaught exceptions, still go stdout (not stderr).

--anders
Jun 08 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d86f8l$1e66$1 digitaldaemon.com...

 Walter wrote:

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 Could we please at least have an answer about these?

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3173


The problem is I haven't spent the time thinking about those yet. Other
stuff always intrudes.
Jun 10 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


Could we please at least have an answer about these?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3173


 
 The problem is I haven't spent the time thinking about those yet. Other
 stuff always intrudes.


The urgency depends on whether we want the people learning D now
to use readf/writef, or use the "good ole" scanf/printf instead ?

If we want them to stop using the C functions before there is
too much to clean up (there more or less is already), then it
should be addressed as soon as possible. Just move "printf" back
to std.c.stdio, where it belongs. Old code can just import that ?

If not, then we continue using implicit "printf" just like before...
Sooner or later the situation would need to get cleaned up, though.

--anders
Jun 10 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:
<snip>

 The urgency depends on whether we want the people learning D now
 to use readf/writef, or use the "good ole" scanf/printf instead ?
 
 If we want them to stop using the C functions before there is
 too much to clean up (there more or less is already), then it
 should be addressed as soon as possible. Just move "printf" back
 to std.c.stdio, where it belongs. Old code can just import that ?
 
 If not, then we continue using implicit "printf" just like before...
 Sooner or later the situation would need to get cleaned up, though.


Along with the claim on ctod.html that "printf rules", as if writef 
doesn't, and the similar statement in the FAQ.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 10 2005
parent "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d8c66p$18cm$1 digitaldaemon.com...

 Along with the claim on ctod.html that "printf rules", as if writef
 doesn't, and the similar statement in the FAQ.


LOL. Thanks for pointing out the anachronisms in the doc, I keep stumbling
across more myself.
Jun 10 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d8bvps$12nq$1 digitaldaemon.com...

 The urgency depends on whether we want the people learning D now
 to use readf/writef, or use the "good ole" scanf/printf instead ?


I don't think it is urgent, for the simple reason that support for C
functions, which include printf, is not going away in D.
Jun 10 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message
 news:d8bvps$12nq$1 digitaldaemon.com...
 

 The urgency depends on whether we want the people learning D now
 to use readf/writef, or use the "good ole" scanf/printf instead ?


 
 I don't think it is urgent, for the simple reason that support for C
 functions, which include printf, is not going away in D.


I'm more concerned about the fact that uncaught error messages are going 
to stdout when they should be going to stderr.

Moreover, the fix is already written.  Surely it would be quicker to 
just put it in than to carry on arguing?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:


 I'm more concerned about the fact that uncaught error messages are going 
 to stdout when they should be going to stderr.
 
 Moreover, the fix is already written.  Surely it would be quicker to 
 just put it in than to carry on arguing?


Actually it is two _different_ fixes and issues...

The error redirect from the current stdout to stderr
shouldn't be at all hard to do regardless of "print" ?

AFAIK, it's like three lines of code to change ? :-P


Changing the print/printf is not exactly "tricky" either,
just tedious since it involves a lot of user code as well.

And someone still needs to clean up "readf" for release,
which probably involves finalizing the D typeinfo first.

Before we have any input methods too, changing the printf
over to writef isn't really all that "urgent" IMHO either.

--anders


PS. I also think "void main" should be addressed sooner
     rather than later, at least *define* it in the spec ?
     (it doesn't have to be implemented just yet, if tricky)
Jun 13 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:
<snip>

 The error redirect from the current stdout to stderr
 shouldn't be at all hard to do regardless of "print" ?


Indeed.  But is there any reason not to put both patches in at the same 
time?

<snip>

 Before we have any input methods too, changing the printf
 over to writef isn't really all that "urgent" IMHO either.


IMHO we shouldn't only be asking whether it's urgent, but also whether 
there's any reason to hold back.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 13 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:


 The error redirect from the current stdout to stderr
 shouldn't be at all hard to do regardless of "print" ?


 
 Indeed.  But is there any reason not to put both patches in at the same 
 time?
 
 <snip>
 

 Before we have any input methods too, changing the printf
 over to writef isn't really all that "urgent" IMHO either.


 
 IMHO we shouldn't only be asking whether it's urgent, but also whether 
 there's any reason to hold back.


I don't think so myself, but if Walter doesn't want to...

=> Maybe easier in "small steps" ? :-)


And it wasn't like printf was going to be removed from D
or anything, just moved back to the proper import module ?

But I'm not holding my breath, I'm doing other things and
will check back in a few months to see how it is going...

--anders
Jun 13 2005
prev sibling next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Wow, that looks like a major update. Thanks!
I'm not sure whether it's time to upgrade, though.
So many things are deprecated in version 0.126.
Jun 08 2005
next sibling parent Geert <gertje gertje.org> writes:
Thanks Walter!

zwang wrote:

 Walter wrote:
 

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 
 Wow, that looks like a major update. Thanks!
 I'm not sure whether it's time to upgrade, though.
 So many things are deprecated in version 0.126.


All the more reason to update!
Jun 08 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
zwang wrote:

 Walter wrote:
 

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 
 Wow, that looks like a major update. Thanks!
 I'm not sure whether it's time to upgrade, though.
 So many things are deprecated in version 0.126.


And so many things changed their behaviour.  Like nested classes and 
unsuccessful AA lookups.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d86gob$1g0e$1 digitaldaemon.com...

 zwang wrote:

 Walter wrote:


 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 Wow, that looks like a major update. Thanks!
 I'm not sure whether it's time to upgrade, though.
 So many things are deprecated in version 0.126.


 And so many things changed their behaviour.  Like nested classes and
 unsuccessful AA lookups.


With the deprecation detection by the compiler, finding the problem areas is
pretty simple, and they're easilly fixed.
Jun 08 2005
parent zwang <nehzgnaw gmail.com> writes:
Walter wrote:

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d86gob$1g0e$1 digitaldaemon.com...
 

zwang wrote:


Walter wrote:



Added inner classes.

http://www.digitalmars.com/d/changelog.html


Wow, that looks like a major update. Thanks!
I'm not sure whether it's time to upgrade, though.
So many things are deprecated in version 0.126.


And so many things changed their behaviour.  Like nested classes and
unsuccessful AA lookups.


 
 
 With the deprecation detection by the compiler, finding the problem areas is
 pretty simple, and they're easilly fixed.
 
 


True. Fixing the problems are fairly easy. What I'm concerned is the 
compatibility issue.
Jun 08 2005
prev sibling next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Thank you for all of that!

-JJR
Jun 08 2005
prev sibling next sibling parent Trevor Parscal <trevorparscal hotmail.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Walter is my hero. No really! He is...

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
Jun 08 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Ummm... I've got a problem ...

 void main()
 {
    Object x;
    
    version (DigitalMars)
    {
        if (x !is null) {}
    }
    else
    {
        if (x !== null) {}
    }
 }

I expected that by using the DigitalMars compiler that I wouldn't get ...

   "test.d(11): '!==' is deprecated, use '!is' instead"

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 9:55:42 PM
Jun 08 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
In article <trch1jhcb7pj.1qubpmdg2vvtf.dlg 40tude.net>, Derek Parnell says...

On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Ummm... I've got a problem ...

 void main()
 {
    Object x;
    
    version (DigitalMars)
    {
        if (x !is null) {}
    }
    else
    {
        if (x !== null) {}
    }
 }

I expected that by using the DigitalMars compiler that I wouldn't get ...

   "test.d(11): '!==' is deprecated, use '!is' instead"

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 9:55:42 PM


That looks like a parsing catch.  As you recall, version blocks must be fully
language-parseable.  The version condition only selects which code block gets
compiled in.  Walter must be catching the use of !== in the parser and erroring
out if so.

Regards,
James Dunne
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jun 2005 12:46:47 +0000 (UTC), James Dunne wrote:


 In article <trch1jhcb7pj.1qubpmdg2vvtf.dlg 40tude.net>, Derek Parnell says...

On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Ummm... I've got a problem ...

 void main()
 {
    Object x;
    
    version (DigitalMars)
    {
        if (x !is null) {}
    }
    else
    {
        if (x !== null) {}
    }
 }

I expected that by using the DigitalMars compiler that I wouldn't get ...

   "test.d(11): '!==' is deprecated, use '!is' instead"

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 9:55:42 PM


 
 That looks like a parsing catch.  As you recall, version blocks must be fully
 language-parseable.  The version condition only selects which code block gets
 compiled in.  Walter must be catching the use of !== in the parser and erroring
 out if so.


Oh I understand what's going on, and I realized that before doing this. So
to be more specific...

WTF do I have to code so I only have to support one source file for
multiple compilers? I don't really want one version of the Build
application source for the GDC compiler and another set of source files for
the DigitalMars compiler. At this stage, I'm going to have to revert to a
macro preprocessor again! I'm sure that is not what Walter envisioned his
D-isciples doing.

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 11:16:32 PM
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:zu8pxspfqpou$.j798zboqpqeo$.dlg 40tude.net...

 WTF do I have to code so I only have to support one source file for
 multiple compilers? I don't really want one version of the Build
 application source for the GDC compiler and another set of source files


for

 the DigitalMars compiler. At this stage, I'm going to have to revert to a
 macro preprocessor again! I'm sure that is not what Walter envisioned his
 D-isciples doing.


Compiling with -d will allow the use of deprecated features.
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jun 2005 09:51:26 -0700, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:zu8pxspfqpou$.j798zboqpqeo$.dlg 40tude.net...

 WTF do I have to code so I only have to support one source file for
 multiple compilers? I don't really want one version of the Build
 application source for the GDC compiler and another set of source files


 for

 the DigitalMars compiler. At this stage, I'm going to have to revert to a
 macro preprocessor again! I'm sure that is not what Walter envisioned his
 D-isciples doing.


 
 Compiling with -d will allow the use of deprecated features.


That IS NOT the problem, Walter. 

I don't want to use deprecated features. 

I want to use the current features, not old ones that are going away
someday. Reasonable, no?

The problem is, that not all compilers are at the same release level, or
will share the same features. So if one wants one's product to be to be
supported with multiple compilers, how does one code their source files?

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:15:50 AM
Jun 08 2005
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
These issues will go away once GDC is up to date and/or D reaches 1.0, 
so why worry and code work-arounds when you can just relax and wait it out?


Derek Parnell wrote:

 On Wed, 8 Jun 2005 09:51:26 -0700, Walter wrote:
 
 

"Derek Parnell" <derek psych.ward> wrote in message
news:zu8pxspfqpou$.j798zboqpqeo$.dlg 40tude.net...


WTF do I have to code so I only have to support one source file for
multiple compilers? I don't really want one version of the Build
application source for the GDC compiler and another set of source files


for


the DigitalMars compiler. At this stage, I'm going to have to revert to a
macro preprocessor again! I'm sure that is not what Walter envisioned his
D-isciples doing.


Compiling with -d will allow the use of deprecated features.


 
 
 That IS NOT the problem, Walter. 
 
 I don't want to use deprecated features. 
 
 I want to use the current features, not old ones that are going away
 someday. Reasonable, no?
 
 The problem is, that not all compilers are at the same release level, or
 will share the same features. So if one wants one's product to be to be
 supported with multiple compilers, how does one code their source files?
Jun 08 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 08 Jun 2005 21:54:55 +0000, clayasaurus wrote:


 These issues will go away once GDC is up to date and/or D reaches 1.0, 
 so why worry and code work-arounds when you can just relax and wait it out?


I'm thinking about the general case, and not specifically the "!is" issue.

Yes, one day in the indeterminate future, GDC will catch up with
DigitalMars, and even more unknown is when v1.0 is going to happen, but
what do I do in the meantime? Are you seriously asking me to never use any
new feature of D until both those events happen? I didn't think so.

The new features are meant to be used, right? I'm sure Walter is not adding
them just because he's got more time than he knows what to do with. 

This problem exists because there was not enough fore thought put in about
the future of how a new language is going to evolve. A solution to this
real-world problem should have been built into the language from the very
beginning. It's probably too late to fix now. Preprocessor - he we come
(again).

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 8:02:14 AM
Jun 08 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


These issues will go away once GDC is up to date and/or D reaches 1.0, 
so why worry and code work-arounds when you can just relax and wait it out?


 
 I'm thinking about the general case, and not specifically the "!is" issue.
 
 Yes, one day in the indeterminate future, GDC will catch up with
 DigitalMars, and even more unknown is when v1.0 is going to happen, but
 what do I do in the meantime? Are you seriously asking me to never use any
 new feature of D until both those events happen? I didn't think so.


And what about the 2.0 features ? Won't they suffer the same fate,
once they start trickling down in the 1.1 versions of the language ?

I agree/sympathize with Derek, sounds like it's preprocessor time.

--anders
Jun 08 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 09 Jun 2005 00:31:30 +0200, Anders F Björklund wrote:


 Derek Parnell wrote:
 

These issues will go away once GDC is up to date and/or D reaches 1.0, 
so why worry and code work-arounds when you can just relax and wait it out?


 
 I'm thinking about the general case, and not specifically the "!is" issue.
 
 Yes, one day in the indeterminate future, GDC will catch up with
 DigitalMars, and even more unknown is when v1.0 is going to happen, but
 what do I do in the meantime? Are you seriously asking me to never use any
 new feature of D until both those events happen? I didn't think so.


 
 And what about the 2.0 features ? Won't they suffer the same fate,
 once they start trickling down in the 1.1 versions of the language ?
 
 I agree/sympathize with Derek, sounds like it's preprocessor time.


I hate to say this, but I suspect this is beyond Walter's abilities to fix
the situation. Its too late. The introduction of any new thing that solves
this will naturally be incompatible with earlier versions of DMD or other
brands of compilers.

The only thing I can come up with so far (and I haven't explored this too
far) is to change the behaviour of the version statement when its in the
form of 'version(id) { . . . }', such that it literally ignores the
characters in between the matching braces when the version identifier
doesn't apply. This would have the same effect as it does now, except that
it will not try to see if the stuff inside the braces is valid D syntax.
That would solve my problem *and* enable a new way of inserting non-D code
into a D source file - e.g. documentation.

But I'd still have to wait for GDC to catch up on that idea too ;-)

-- 
Derek
Melbourne, Australia
9/06/2005 9:33:09 AM
Jun 08 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
It would still have to count curly braces, at the least, because a 
literal reading of your suggestion means:

version (asdf)
{
   if (true)
   {
      writef("only shown for version=asdf!");
   }

   writef("shown always.");
} // <-- error.

-[Unknown]



 On Thu, 09 Jun 2005 00:31:30 +0200, Anders F Björklund wrote:
 
 

Derek Parnell wrote:



These issues will go away once GDC is up to date and/or D reaches 1.0, 
so why worry and code work-arounds when you can just relax and wait it out?


I'm thinking about the general case, and not specifically the "!is" issue.

Yes, one day in the indeterminate future, GDC will catch up with
DigitalMars, and even more unknown is when v1.0 is going to happen, but
what do I do in the meantime? Are you seriously asking me to never use any
new feature of D until both those events happen? I didn't think so.


And what about the 2.0 features ? Won't they suffer the same fate,
once they start trickling down in the 1.1 versions of the language ?

I agree/sympathize with Derek, sounds like it's preprocessor time.


 
 
 I hate to say this, but I suspect this is beyond Walter's abilities to fix
 the situation. Its too late. The introduction of any new thing that solves
 this will naturally be incompatible with earlier versions of DMD or other
 brands of compilers.
 
 The only thing I can come up with so far (and I haven't explored this too
 far) is to change the behaviour of the version statement when its in the
 form of 'version(id) { . . . }', such that it literally ignores the
 characters in between the matching braces when the version identifier
 doesn't apply. This would have the same effect as it does now, except that
 it will not try to see if the stuff inside the braces is valid D syntax.
 That would solve my problem *and* enable a new way of inserting non-D code
 into a D source file - e.g. documentation.
 
 But I'd still have to wait for GDC to catch up on that idea too ;-)
Jun 08 2005
next sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d8803s$2u7s$1 digitaldaemon.com>, Unknown W. Brackets says...

It would still have to count curly braces, at the least, because a 
literal reading of your suggestion means:


Right. And it'd also need to keep track of openning and closing quotation marks
in string literals so that
version(id)
{
char[] s = "}"; 
}
wouldn't mess it up.

jcc7
Jun 08 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Don't forget comments!

-[Unknown]



 In article <d8803s$2u7s$1 digitaldaemon.com>, Unknown W. Brackets says...
 

It would still have to count curly braces, at the least, because a 
literal reading of your suggestion means:


 
 
 Right. And it'd also need to keep track of openning and closing quotation marks
 in string literals so that
 version(id)
 {
 char[] s = "}"; 
 }
 wouldn't mess it up.
 
 jcc7
Jun 08 2005
parent J C Calvarese<technocrat7 gmail.com> writes:
In article <d88f6c$br5$1 digitaldaemon.com>, Unknown W. Brackets says...

Don't forget comments!

-[Unknown]


Yep. Comments, too.

jcc7
Jun 08 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 08 Jun 2005 16:48:14 -0700, Unknown W. Brackets wrote:


 It would still have to count curly braces, at the least, because a 
 literal reading of your suggestion means:
 
 version (asdf)
 {
    if (true)
    {
       writef("only shown for version=asdf!");
    }
 
    writef("shown always.");
 } // <-- error.


I said the stuff in between the braces, that is the version statement's
braces would be ignored. Thus your example above is equivalent to ...

  version (asdf)
  {
     Any text at all can go here (except unmatched braces)
  }

I think you were trying to say ...

 version (asdf)
 {
    writef("only shown for version=asdf!");
 }
 writef("shown always.");

I know its not perfect but it could be a starting point for discussion and
thought. Though I believe its a hopeless situation now.

Anyhow, I'd better go back to porting my macro processor to D ;-)

-- 
Derek
Melbourne, Australia
9/06/2005 10:29:53 AM
Jun 08 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I think you missed my point.  I wrote it correctly, but showing you how 
you would interpret it with your statement.  Put another way....

version (x)
{
    {
       "nested scope";
    }
    {
       "nested scope";
    }
}

Both "nested scope"s should be INSIDE the version statement, yes?  But, 
if the version is matched like ~\{[^}]*\}~ then, it looks to the 
COMPILER like:

/*version (x)
{
    {
       "nested scope";
    }*/
    {
       "nested scope";
    }
}

Or, in other words:

{"nested scope";}}

Do you see why?  The same goes for /* } */ and " } ".

-[Unknown]



 On Wed, 08 Jun 2005 16:48:14 -0700, Unknown W. Brackets wrote:
 
 

It would still have to count curly braces, at the least, because a 
literal reading of your suggestion means:

version (asdf)
{
   if (true)
   {
      writef("only shown for version=asdf!");
   }

   writef("shown always.");
} // <-- error.


 
 
 I said the stuff in between the braces, that is the version statement's
 braces would be ignored. Thus your example above is equivalent to ...
 
   version (asdf)
   {
      Any text at all can go here (except unmatched braces)
   }
 
 I think you were trying to say ...
 
  version (asdf)
  {
     writef("only shown for version=asdf!");
  }
  writef("shown always.");
 
 I know its not perfect but it could be a starting point for discussion and
 thought. Though I believe its a hopeless situation now.
 
 Anyhow, I'd better go back to porting my macro processor to D ;-)
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 08 Jun 2005 21:08:36 -0700, Unknown W. Brackets wrote:


 I think you missed my point.  I wrote it correctly, but showing you how 
 you would interpret it with your statement. Put another way....
 
 version (x)
 {
     {
        "nested scope";
     }
     {
        "nested scope";
     }
 }
 
 Both "nested scope"s should be INSIDE the version statement, yes?  But, 
 if the version is matched like ~\{[^}]*\}~ 


But that's not how the compiler works. It already does nested versions
quite well.

version(ABC) {
   version(DEF) 
   {
       if (abc) { ... } // only if both ABC and DEF versions set
   }

   version(GHJ)
   {
       if (abc) { ... } // only if both ABC and GHJ versions set.
   }
}



 then, it looks to the COMPILER like:
 
 /*version (x)
 {
     {
        "nested scope";
     }*/
     {
        "nested scope";
     }
 }
 
 Or, in other words:
 
 {"nested scope";}}

 Do you see why?  The same goes for /* } */ and " } ".


Have you tried it? I'm sure you'll find that the compiler just does not
work like that. The matching brace for a version statement is not the first
'}' that it comes across, but the first *matching* '}' it comes across. It
allows nested braces.

-- 
Derek
Melbourne, Australia
9/06/2005 2:27:49 PM
Jun 08 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
*slaps forehead...*

This is not what I'm talking about!  I'm talking about:

"such that it literally ignores the
characters in between the matching braces when the version identifier
doesn't apply."

NOT about the current way the compiler works!

-[Unknown]



 On Wed, 08 Jun 2005 21:08:36 -0700, Unknown W. Brackets wrote:
 
 

I think you missed my point.  I wrote it correctly, but showing you how 
you would interpret it with your statement. Put another way....

version (x)
{
    {
       "nested scope";
    }
    {
       "nested scope";
    }
}

Both "nested scope"s should be INSIDE the version statement, yes?  But, 
if the version is matched like ~\{[^}]*\}~ 


 
 
 But that's not how the compiler works. It already does nested versions
 quite well.
 
 version(ABC) {
    version(DEF) 
    {
        if (abc) { ... } // only if both ABC and DEF versions set
    }
 
    version(GHJ)
    {
        if (abc) { ... } // only if both ABC and GHJ versions set.
    }
 }
 
 
 

then, it looks to the COMPILER like:

/*version (x)
{
    {
       "nested scope";
    }*/
    {
       "nested scope";
    }
}

Or, in other words:

{"nested scope";}}

Do you see why?  The same goes for /* } */ and " } ".


 
 
 Have you tried it? I'm sure you'll find that the compiler just does not
 work like that. The matching brace for a version statement is not the first
 '}' that it comes across, but the first *matching* '}' it comes across. It
 allows nested braces.
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 08 Jun 2005 21:51:50 -0700, Unknown W. Brackets wrote:


 *slaps forehead...*
 
 This is not what I'm talking about!  I'm talking about:
 
 "such that it literally ignores the
 characters in between the matching braces when the version identifier
 doesn't apply."
 
 NOT about the current way the compiler works!


Huh?  I don't get it then. Sorry.

What I said meant that one would first find the matching braces, then
ignore the stuff in between them. What am I saying wrong?

-- 
Derek
Melbourne, Australia
9/06/2005 3:14:52 PM
Jun 08 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
The point is it would still have to analyze it.  Imagine if D 2.0 allowed:

if (string ~= /a\}/i)

Or some such.  There's a } in there, and it's not in quotes, or a 
comment, or anything.  In fact, it looks very much like a closing curly 
brace, does it not?

Another example.  Say, for some STRANGE reason, D 2.0 allowed:

a /+ 5;

Being:

a = (a / 5) + 5;

Now, obviously this is unlikely, but it would again confuse the parsing 
you're suggesting.  Since there's no way to predict future developments 
perfectly (what if a heredoc syntax was added?) it's impossible to make 
such a syntax work for any case.

-[Unknown]



 On Wed, 08 Jun 2005 21:51:50 -0700, Unknown W. Brackets wrote:
 
 

*slaps forehead...*

This is not what I'm talking about!  I'm talking about:

"such that it literally ignores the
characters in between the matching braces when the version identifier
doesn't apply."

NOT about the current way the compiler works!


 
 
 Huh?  I don't get it then. Sorry.
 
 What I said meant that one would first find the matching braces, then
 ignore the stuff in between them. What am I saying wrong?
Jun 09 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 09 Jun 2005 00:40:19 -0700, Unknown W. Brackets wrote:


 The point is it would still have to analyze it.


Yeah, whatever. Look, I'm over it. 

Personally I don't think there is a solution, so I'm resigned to using some
other tool to develop with from now on. If someone comes up with a great
way of achieving the 'grand' aim of only maintaining one set of source
files per application, just let us know. Currently, D alone is not enough;
it falls short of ever being able to do this, unlike C and C++. In short, I
need an additional tool so I can reduce my development costs.

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:44:59 PM
Jun 09 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:15iyeaoc4m2un$.k32eg0afi011.dlg 40tude.net...

 Personally I don't think there is a solution, so I'm resigned to using


some

 other tool to develop with from now on. If someone comes up with a great
 way of achieving the 'grand' aim of only maintaining one set of source
 files per application, just let us know. Currently, D alone is not enough;
 it falls short of ever being able to do this, unlike C and C++. In short,


I

 need an additional tool so I can reduce my development costs.


The C and C++ preprocessor cannot do this in the *general* case. The reason
is because the preprocessor works on preprocessor tokens, not on text. If
any new tokens were added, then the older preprocessors are obligated to
fail, even on the false conditionals.
Jun 10 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 10 Jun 2005 00:06:21 -0700, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:15iyeaoc4m2un$.k32eg0afi011.dlg 40tude.net...

 Personally I don't think there is a solution, so I'm resigned to using


 some

 other tool to develop with from now on. If someone comes up with a great
 way of achieving the 'grand' aim of only maintaining one set of source
 files per application, just let us know. Currently, D alone is not enough;
 it falls short of ever being able to do this, unlike C and C++. In short,


 I

 need an additional tool so I can reduce my development costs.


 
 The C and C++ preprocessor cannot do this in the *general* case. The reason
 is because the preprocessor works on preprocessor tokens, not on text. If
 any new tokens were added, then the older preprocessors are obligated to
 fail, even on the false conditionals.


Yes, I understand this. I have a general macro processor that I've written
and I'm currently porting it to D. It is able to handle the general case.
Once I've completed the port I'll add it to DSource for review, etc...


-- 
Derek Parnell
Melbourne, Australia
10/06/2005 8:12:46 PM
Jun 10 2005
parent "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1ug68xy67nop6$.4jufrs60obd0.dlg 40tude.net...

 Yes, I understand this. I have a general macro processor that I've written
 and I'm currently porting it to D. It is able to handle the general case.
 Once I've completed the port I'll add it to DSource for review, etc...


I think that'll be cool.

P.S. I never understood why the C preprocessor was redefined from being a
text preprocessor to a token preprocessor. I see no advantage to the latter,
and it makes for a lot of mess in the implementation.
Jun 10 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <tb0gyescbf38.hee66wywoqdw.dlg 40tude.net>, Derek Parnell says...

On Wed, 08 Jun 2005 16:48:14 -0700, Unknown W. Brackets wrote:


 It would still have to count curly braces, at the least, because a 
 literal reading of your suggestion means:
 
 version (asdf)
 {
    if (true)
    {
       writef("only shown for version=asdf!");
    }
 
    writef("shown always.");
 } // <-- error.


I said the stuff in between the braces, that is the version statement's
braces would be ignored. Thus your example above is equivalent to ...

  version (asdf)
  {
     Any text at all can go here (except unmatched braces)
  }

I think you were trying to say ...

 version (asdf)
 {
    writef("only shown for version=asdf!");
 }
 writef("shown always.");

I know its not perfect but it could be a starting point for discussion and
thought. Though I believe its a hopeless situation now.


Derek, I'm jumping into the middle of the thread here, please feel free to
correct me if I'm way off base here. :)

Part of the problem is that DMD (at least by inspecting the front-end) has a
lexer that provides tokens to the parser in a limited read-ahead fashion.  I
don't think it would be hard to get the lexer to do a deeper scan (like you
propose) ahead of any given parser production, but it would still crumble when
it encounters a non-supported token.  

IMO, the only time this would fail would be in the case of '$' being introduced
as you mentioned earlier.  Even with version(), the older lexer is going to trip
on any new tokens should they be introduced.  One way to escape the problem is
to make DMD 'preprocess' version blocks as to avoid a full-on lex of them.
Somehow, I don't think this is going to fly with Walter. :(

A compromise would be for DMD to produce 'unknown' tokens from the lexer, to let
the parser cough up an error upon encountering them.  *That* would solve the
problem now and from here on out, since the parser would skip version() branches
(with all their possibly unsupported tokens) that it doesn't need to /parse/.  I
also think that it would be easier to implement into both DMD and GDC without
disrupting the overall compiler design.

Now, will Walter go for it?

- EricAnderton at yahoo
Jun 09 2005
parent pragma <pragma_member pathlink.com> writes:
Forget everything I said.  

I'm looking at the frontend source now.  Derek is right, there's no way to

an existing production (like 'x = foo ?: bar;') in D without introducing some
rudimentary preprocessing behavior.

The problem lies in the fact that all version() branches must be valid D code in
order to make their way into the parse tree.  After several semantic passes, the
tree is then evaulated, and steers itself down the appropriate version()
branches.  Then we get binary output from that last, version() sensitive, pass.

So the only way to avoid these problems with the existing rules and compiler
family is to code to the least-common-denominator of all compilers, which
defeats some of the purpose behind version().  



Derek, I'm jumping into the middle of the thread here, please feel free to
correct me if I'm way off base here. :)

Part of the problem is that DMD (at least by inspecting the front-end) has a
lexer that provides tokens to the parser in a limited read-ahead fashion.  I
don't think it would be hard to get the lexer to do a deeper scan (like you
propose) ahead of any given parser production, but it would still crumble when
it encounters a non-supported token.  

IMO, the only time this would fail would be in the case of '$' being introduced
as you mentioned earlier.  Even with version(), the older lexer is going to trip
on any new tokens should they be introduced.  One way to escape the problem is
to make DMD 'preprocess' version blocks as to avoid a full-on lex of them.
Somehow, I don't think this is going to fly with Walter. :(

A compromise would be for DMD to produce 'unknown' tokens from the lexer, to let
the parser cough up an error upon encountering them.  *That* would solve the
problem now and from here on out, since the parser would skip version() branches
(with all their possibly unsupported tokens) that it doesn't need to /parse/.  I
also think that it would be easier to implement into both DMD and GDC without
disrupting the overall compiler design.

Now, will Walter go for it?

- EricAnderton at yahoo
Jun 09 2005
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
Anders F Björklund wrote:

 Derek Parnell wrote:
 

 These issues will go away once GDC is up to date and/or D reaches 
 1.0, so why worry and code work-arounds when you can just relax and 
 wait it out?



 I'm thinking about the general case, and not specifically the "!is" 
 issue.

 Yes, one day in the indeterminate future, GDC will catch up with
 DigitalMars, and even more unknown is when v1.0 is going to happen, but
 what do I do in the meantime? Are you seriously asking me to never use 
 any
 new feature of D until both those events happen? I didn't think so.


 
 
 And what about the 2.0 features ? Won't they suffer the same fate,
 once they start trickling down in the 1.1 versions of the language ?
 
 I agree/sympathize with Derek, sounds like it's preprocessor time.
 
 --anders


Umm... am I the only one under the impression that Walter will keep a 
1.0 branch and a 2.0 branch seperate, and maintain 1.0 with bug fixes, 
and 2.0 with new features? This way we have a stable bug-free standard 
version, and the cutting edge version for D enthusiats.

Though I sympathize with Derek, how hard can it be for D to ignore code 
in version blocks when it is not that version? The only problem I see is 
you will only catch compiler errors when you have 'version' defined, it 
just means the programmer has to a little more maintainence for every 
version they have. Maybe there can be a compile switch, -noversionparse, 
that you can enable to disable parsing of the versions if that version 
was not defined.
Jun 08 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <1b0qcoubwa4si.v389g1menc5k.dlg 40tude.net>, Derek Parnell says...

On Wed, 08 Jun 2005 21:54:55 +0000, clayasaurus wrote:


 These issues will go away once GDC is up to date and/or D reaches 1.0, 
 so why worry and code work-arounds when you can just relax and wait it out?


I'm thinking about the general case, and not specifically the "!is" issue.

Yes, one day in the indeterminate future, GDC will catch up with
DigitalMars, and even more unknown is when v1.0 is going to happen, but
what do I do in the meantime? Are you seriously asking me to never use any
new feature of D until both those events happen? I didn't think so.

The new features are meant to be used, right? I'm sure Walter is not adding
them just because he's got more time than he knows what to do with. 

This problem exists because there was not enough fore thought put in about
the future of how a new language is going to evolve. A solution to this
real-world problem should have been built into the language from the very
beginning. It's probably too late to fix now. Preprocessor - he we come
(again).


I think the real issue is that GDC isn't maintained at the frenetic pace DMD is.
And because D is pre-1.0, there's little reason to move slowly with changes.
Sure, feature changes can be painful, but it's what I expect of D until the
language is standardized.  Afterwords, things will likely work the way they do
in the C++ world: new features are announced long before the standard is
finalized, and deprecated features are supported for years after the standard is
released.  With D compilers being less complex to implement than C++ compilers,
I would expect nearly full feature support in popular compilers by the time any
post-1.0 standard is released.


Sean
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jun 2005 23:02:13 +0000 (UTC), Sean Kelly wrote:


 In article <1b0qcoubwa4si.v389g1menc5k.dlg 40tude.net>, Derek Parnell says...

On Wed, 08 Jun 2005 21:54:55 +0000, clayasaurus wrote:


 These issues will go away once GDC is up to date and/or D reaches 1.0, 
 so why worry and code work-arounds when you can just relax and wait it out?


I'm thinking about the general case, and not specifically the "!is" issue.

Yes, one day in the indeterminate future, GDC will catch up with
DigitalMars, and even more unknown is when v1.0 is going to happen, but
what do I do in the meantime? Are you seriously asking me to never use any
new feature of D until both those events happen? I didn't think so.

The new features are meant to be used, right? I'm sure Walter is not adding
them just because he's got more time than he knows what to do with. 

This problem exists because there was not enough fore thought put in about
the future of how a new language is going to evolve. A solution to this
real-world problem should have been built into the language from the very
beginning. It's probably too late to fix now. Preprocessor - he we come
(again).


 
 I think the real issue is that GDC isn't maintained at the frenetic pace DMD
is.


Why stop at GDC? What about 'xyz' and the soon to be famous 'qwerty' D
compiler?! Think in general terms and you'll see we really *do* have a
problem.


 And because D is pre-1.0, there's little reason to move slowly with changes.


Okay, so along comes 1.01 with a new feature. How long should I wait for
all the other compilers I want to support to catch up? What if some of
those never catch up but are still in use. Borland C v5.5 has lots of
adherents.


 Sure, feature changes can be painful, but it's what I expect of D until the
 language is standardized.  Afterwords, things will likely work the way they do
 in the C++ world: new features are announced long before the standard is
 finalized, and deprecated features are supported for years after the standard
is
 released.  With D compilers being less complex to implement than C++ compilers,
 I would expect nearly full feature support in popular compilers by the time any
 post-1.0 standard is released.


Yes, but irrelevant. How does one support in a *single* source base, the
various *incompatible* syntaxes that may exist at *any* given time? Think
in general terms and not specific compilers or language features.

-- 
Derek
Melbourne, Australia
9/06/2005 9:18:00 AM
Jun 08 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <19gr67kb4q1fw.vwbenzrtgmvv$.dlg 40tude.net>, Derek Parnell says...

 And because D is pre-1.0, there's little reason to move slowly with changes.


Okay, so along comes 1.01 with a new feature. How long should I wait for
all the other compilers I want to support to catch up? What if some of
those never catch up but are still in use. Borland C v5.5 has lots of
adherents.


True enough.  But should the development of a language be halted for the sake of
backwards compatibility?  Or do you have a suggestion for how this could be
resolved another way.  I'm drawing a blank.


Yes, but irrelevant. How does one support in a *single* source base, the
various *incompatible* syntaxes that may exist at *any* given time? Think
in general terms and not specific compilers or language features.


For D, my only suggestion would be to ignore version blocks even for syntax
checking (assuming they aren't already).  If the version flag isn't set, the
block doesn't exist at all.  This doesn't solve the more general problem of new
operators and such that can't be quite so easily isolated, but I don't see the
language changing much at that level once we hit 1.0.  I'm personally not
willing to introduce macros into the language just to solve this particular
problem.  I'd rather compiler implementors have some incentive to update their
code within a reasonable timeframe.  And when you get down to it, no one says
you have to use the new features anyway.  Perhaps not an appealing option (this
still bugs me with C++ compiler conformance) but at least it's one we're used
to.


Sean
Jun 09 2005
parent Derek Parnell <derek psych.ward> writes:
On Thu, 9 Jun 2005 14:37:27 +0000 (UTC), Sean Kelly wrote:


 In article <19gr67kb4q1fw.vwbenzrtgmvv$.dlg 40tude.net>, Derek Parnell says...

 And because D is pre-1.0, there's little reason to move slowly with changes.


Okay, so along comes 1.01 with a new feature. How long should I wait for
all the other compilers I want to support to catch up? What if some of
those never catch up but are still in use. Borland C v5.5 has lots of
adherents.


 
 True enough.  But should the development of a language be halted for the sake
of
 backwards compatibility?


Of course not.


  Or do you have a suggestion for how this could be
 resolved another way.  I'm drawing a blank.


Me too. This is a storm in a teacup. An external macro tool is the only
reasonable course of action to solve this problem. That's the approach I'll
be taking.

-- 
Derek Parnell
Melbourne, Australia
10/06/2005 7:02:33 AM
Jun 09 2005
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
These issues NEVER go away.  Unless this class of problem is 
dealt with cleanly, it will hang on forever.  There will always 
be features that are supported by one compiler, and not by 
another.  You can't even deal with it with a decree from the 
government.  (Ada tried.  It didn't work.)

Some people have gone as far as to write preprocessors just so 
that they only need to maintain one file of code for their program.

All that said, exactly HOW it should be dealt with isn't clear to 
me.  C/C++ handles it by not caring about what's in the paths 
through the code that are #ifdef'd out.  I understand the good 
reasons why this is not the preferred choice...but that doesn't 
say how it SHOULD be dealt with.  Particularly when something as 
linguistically basic as !is gets involved.  Up until that was 
defined, it was a clear grammatical error.

The only thing that occurred to me is to put a "not parseable" 
flag on a block.  I don't need to say why that's a bad idea, but 
it might be the best alternative.  (OTOH, it would need to be a 
distinctive flag, and not easily confused with something that 
might mean something else.  All that occurs to me is:
<unparseable>{....}</unparseable>
And it would be an error to omit the closing tag, or for the tag 
to be used outside a version statement.

clayasaurus wrote:

 These issues will go away once GDC is up to date and/or D reaches 1.0, 
 so why worry and code work-arounds when you can just relax and wait it out?
 
 
 Derek Parnell wrote:
 

 On Wed, 8 Jun 2005 09:51:26 -0700, Walter wrote:



 "Derek Parnell" <derek psych.ward> wrote in message
 news:zu8pxspfqpou$.j798zboqpqeo$.dlg 40tude.net...


 WTF do I have to code so I only have to support one source file for
 multiple compilers? I don't really want one version of the Build
 application source for the GDC compiler and another set of source files



 for


 the DigitalMars compiler. At this stage, I'm going to have to revert 
 to a
 macro preprocessor again! I'm sure that is not what Walter 
 envisioned his
 D-isciples doing.



 Compiling with -d will allow the use of deprecated features.




 That IS NOT the problem, Walter.
 I don't want to use deprecated features.
 I want to use the current features, not old ones that are going away
 someday. Reasonable, no?

 The problem is, that not all compilers are at the same release level, or
 will share the same features. So if one wants one's product to be to be
 supported with multiple compilers, how does one code their source files?
Jun 12 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, that's similar to how MySQL handles this.

Basically, they have you use a specially formatted comment, of this syntax:

/*!40001 ... */

Which means, only execute the code inside the ... if the version number 
is equal to or greater than the number in the comment.

The downside, of course, is that they neglected to add a way to do the 
opposite - include code for versions OLDER than that.

The advantage is that any D compiler will handle comments, so if dmd 
0.125 sees:

if (abc /+(dmd_126) !is /* +/ !== /+(dmd_126) */ +/ xyz)

Well, I think you get my point.  The clear downsides to this are that it 
makes it a lot more complicated to parse, both for the compiler and much 
more importantly for code editing and analysis tools, and it just plain 
looks ugly.

I like version a lot myself.  It may not solve every possible problem, 
but nothing does.

-[Unknown]



 These issues NEVER go away.  Unless this class of problem is dealt with 
 cleanly, it will hang on forever.  There will always be features that 
 are supported by one compiler, and not by another.  You can't even deal 
 with it with a decree from the government.  (Ada tried.  It didn't work.)
 
 Some people have gone as far as to write preprocessors just so that they 
 only need to maintain one file of code for their program.
 
 All that said, exactly HOW it should be dealt with isn't clear to me.  
 C/C++ handles it by not caring about what's in the paths through the 
 code that are #ifdef'd out.  I understand the good reasons why this is 
 not the preferred choice...but that doesn't say how it SHOULD be dealt 
 with.  Particularly when something as linguistically basic as !is gets 
 involved.  Up until that was defined, it was a clear grammatical error.
 
 The only thing that occurred to me is to put a "not parseable" flag on a 
 block.  I don't need to say why that's a bad idea, but it might be the 
 best alternative.  (OTOH, it would need to be a distinctive flag, and 
 not easily confused with something that might mean something else.  All 
 that occurs to me is:
 <unparseable>{....}</unparseable>
 And it would be an error to omit the closing tag, or for the tag to be 
 used outside a version statement.
Jun 12 2005
parent Derek Parnell <derek psych.ward> writes:
On Sun, 12 Jun 2005 22:55:20 -0700, Unknown W. Brackets wrote:


 Well, that's similar to how MySQL handles this.
 
 Basically, they have you use a specially formatted comment, of this syntax:
 
 /*!40001 ... */
 
 Which means, only execute the code inside the ... if the version number 
 is equal to or greater than the number in the comment.
 
 The downside, of course, is that they neglected to add a way to do the 
 opposite - include code for versions OLDER than that.
 
 The advantage is that any D compiler will handle comments, so if dmd 
 0.125 sees:
 
 if (abc /+(dmd_126) !is /* +/ !== /+(dmd_126) */ +/ xyz)


Well like I said, I no longer think that this problem is in the compiler's
domain. I'm now going to handle it with an macro processor tool. 

For example, in a file called dmdversion.mac I'll have something like ...

  if [[$dmd]] >= "000.126"
  set $aint = !is
  else
  set $aint = !==
  endif

And in my source code file I'll have this sort of thing...
  include dmdversion.mac
 . . .
 if (abc [[$aint]] xyz)

And then compile it with the command line ...

  build source.mac -set$dmd=000.126


-- 
Derek Parnell
Melbourne, Australia
13/06/2005 7:22:35 PM
Jun 13 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1tnxfysc1e2cb.183d02rddcelx$.dlg 40tude.net...

 Compiling with -d will allow the use of deprecated features.


 That IS NOT the problem, Walter.
 I don't want to use deprecated features.

 I want to use the current features, not old ones that are going away
 someday. Reasonable, no?

 The problem is, that not all compilers are at the same release level, or
 will share the same features. So if one wants one's product to be to be
 supported with multiple compilers, how does one code their source files?


In the future post 1.0 era, I expect predefined version identifiers will be
put in for new features, like D_InlineAsm is today.
Jun 08 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jun 2005 15:56:17 -0700, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:1tnxfysc1e2cb.183d02rddcelx$.dlg 40tude.net...

 Compiling with -d will allow the use of deprecated features.


 That IS NOT the problem, Walter.
 I don't want to use deprecated features.

 I want to use the current features, not old ones that are going away
 someday. Reasonable, no?

 The problem is, that not all compilers are at the same release level, or
 will share the same features. So if one wants one's product to be to be
 supported with multiple compilers, how does one code their source files?


 
 In the future post 1.0 era, I expect predefined version identifiers will be
 put in for new features, like D_InlineAsm is today.


Doesn't solve the problem. Once I put in use of the '$' token, the GDC
compiler couldn't be used to compile the Build application. No amount of
version() stuff could have solved that one.

-- 
Derek
Melbourne, Australia
9/06/2005 9:15:45 AM
Jun 08 2005
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
How open would you be, at some point, to having a public or private 
versioning system?  As the documentation says:

http://www.digitalmars.com/d/pretod.html
"By making the D compiler open source, it will largely avoid the problem 
of syntactical backwards compatibility."

A step toward this would be, for example, giving certain people read 
access to changes to the frontend, as they happen.  Of course, these 
people would hopefully be responsible enough to wait for things to set 
in the ground before implementing them in their own work, but it would 
give forewarning even in this case.

Then again, maybe the idea is to lose all the momentum after 1.0, and 
become another C :P.

-[Unknown]



 In the future post 1.0 era, I expect predefined version identifiers will be
 put in for new features, like D_InlineAsm is today.
Jun 08 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Derek Parnell wrote:
<snip>

 The problem is, that not all compilers are at the same release level, or
 will share the same features. So if one wants one's product to be to be
 supported with multiple compilers, how does one code their source files?


By using deprecated features.

AIUI the whole point of the -d option is to enable legacy code to work 
on modern compilers.  I realise you want to modernise your code, but 
you're trying to rush into it too quickly.

Code for the lowest common denominator of compilers you want to support. 
  As that lowest common denominator becomes more modernised, _then_ 
modernise your code to keep up with it.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 09 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Ummm... I've got a problem ...
 
  void main()
  {
     Object x;
     
     version (DigitalMars)
     {
         if (x !is null) {}
     }
     else
     {
         if (x !== null) {}
     }
  }
 
 I expected that by using the DigitalMars compiler that I wouldn't get ...
 
    "test.d(11): '!==' is deprecated, use '!is' instead"


Since versions are not #if, I don't think there is any way
to make the same source code compile on new DMD and old DMD...
(or GDC, which is at DMD 0.125 thanks to David heroic efforts)

Which leaves the option towards the usual:
1) Require DMD 0.126 and above, in your docs
2) Use the deprecated features and the -d flag


Too bad that there seems to be no way to make it compile for both,
like you could do with C. (which seems to be better for maintenance)
This is not exactly the first time that this has happened, either.

But I guess that's what life with a developing language is ?


FWIW, Java has the same problem.

--anders

PS. What about the there-is-no-spoon option ? (alias spoon bool;)
     void main()
     {
       Object x;
       if (x) {}
     }
     Or are we still hoping for those expressions to be illegal ?
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 08 Jun 2005 15:33:36 +0200, Anders F Björklund wrote:


 Derek Parnell wrote:
 

 Ummm... I've got a problem ...
 
  void main()
  {
     Object x;
     
     version (DigitalMars)
     {
         if (x !is null) {}
     }
     else
     {
         if (x !== null) {}
     }
  }
 
 I expected that by using the DigitalMars compiler that I wouldn't get ...
 
    "test.d(11): '!==' is deprecated, use '!is' instead"


 
 Since versions are not #if, I don't think there is any way
 to make the same source code compile on new DMD and old DMD...
 (or GDC, which is at DMD 0.125 thanks to David heroic efforts)
 
 Which leaves the option towards the usual:
 1) Require DMD 0.126 and above, in your docs
 2) Use the deprecated features and the -d flag


Sorry, neither is acceptable. Today we are only talking about deprecated
functionality, but it can (and has) been deeper syntax issues like the '$'
introduction.

Unless Walter provides a way, I will be forced into using a preprocessor to
generate compilable source code for all the platforms I am hoping to
support. This means I also have to make available multiple editions of the
source files available so people can download the one(s) they need. Just
plain stupidity!

[snip]


 PS. What about the there-is-no-spoon option ? (alias spoon bool;)
      void main()
      {
        Object x;
        if (x) {}
      }
      Or are we still hoping for those expressions to be illegal ?


I don't care if it is illegal or not; to me this form is not sufficiently
expressing my meaning. I regard it as an abbreviation where one is not
appropriate. Of course, that is only a personal opinion ;-)

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 11:53:16 PM
Jun 08 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Unless Walter provides a way, I will be forced into using a preprocessor to
 generate compilable source code for all the platforms I am hoping to
 support. This means I also have to make available multiple editions of the
 source files available so people can download the one(s) they need. Just
 plain stupidity!


Yes, that is a third option...

As far as I know, that was the option that the Java libraries
resorted to in order to make the same source code compilable
by different versions (generations) of the language compiler.

Like when switching from JDK 1.1.8 to 1.3.1, or 1.4.2 to 1.5.0

Then again, Java doesn't have *any* conditional compilation ?
But D has, even if it's not as "flexible" as a preprocessor is.
So there should be some way to address this problem that D has.

--anders
Jun 08 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:skmeququbanx$.a6mchwy1wg9c.dlg 40tude.net...

 Unless Walter provides a way, I will be forced into using a preprocessor


to

 generate compilable source code for all the platforms I am hoping to
 support. This means I also have to make available multiple editions of the
 source files available so people can download the one(s) they need. Just
 plain stupidity!


But that's the point of having the -d switch!

And since compiler updates are free, there's no reason to support older
versions once GDC gets updated.
Jun 08 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 But that's the point of having the -d switch!
 
 And since compiler updates are free, there's no reason to support older
 versions once GDC gets updated.


I've been wondering whether it would be worthwhile to
add something to flag which language version is needed ?

Like it's done in Perl:
"require v5.6.1;"
(sure there are others)

Maybe a pragma or something would do the trick in D code ?
The idea is to forward : "this code needs DMD >= 0.126".

--anders
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d8793u$26v2$1 digitaldaemon.com...

 I've been wondering whether it would be worthwhile to
 add something to flag which language version is needed ?

 Like it's done in Perl:
 "require v5.6.1;"
 (sure there are others)

 Maybe a pragma or something would do the trick in D code ?
 The idea is to forward : "this code needs DMD >= 0.126".


I'd rather do such things by adding version identifiers for specific
features. One reason is my experience with such sequence numbers in the C++
world - they are fairly useless - but predefined macros for specific
features works out rather well.
Jun 09 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Unknown W. Brackets wrote:


 I write forum software in PHP which utilizes MySQL, as I've mentioned 
 before.  I help provide support.  If *nothing else*, I can attest: just 
 because updates are free, doesn't mean:
   - competing compiler vendors (e.g. writing the only QNX version) will 
 update.
   - everyone, especially people who are not full-time developers will 
 update.
   - people will even bother to check/know if they are using an old version.


Or:
- That the time that it takes the people to perform the update is free
- That the brand new version will actually work, and will work better
- That the fixes in the new version doesn't introduce brand new bugs

Life on the "bleeding edge" is sometimes pretty painful...
Better then to use an old version, with security patches ?
Lots of distributions freeze the version numbers for years.

--anders
Jun 08 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
In this case, 4.3.11 is/was a security fix release.  There are security 
holes in all of the old versions - and not only have they not updated, 
they have not even compiled in patches or anything.  These are old, 
insecure, virgin compiles of PHP.  I'll never understand it - but it 
definately happens.

-[Unknown]



 Or:
 - That the time that it takes the people to perform the update is free
 - That the brand new version will actually work, and will work better
 - That the fixes in the new version doesn't introduce brand new bugs
 
 Life on the "bleeding edge" is sometimes pretty painful...
 Better then to use an old version, with security patches ?
 Lots of distributions freeze the version numbers for years.
 
 --anders
Jun 08 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:d87d35$2at4$1 digitaldaemon.com...

 Just my opinion, though.  And, no, I'm not being so helpful as proposing
 a solution.


I know upgrades that require source code changes suck. But I hope you'll
find that this one is worth it.
Jun 08 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I didn't mean to imply it wasn't - and, in this time, while D is not yet 
"stable" and has not reached 1.0, it's fine.  I don't mind the version 
clashes one bit.

It's after 1.0 that I will, should another occur at that time.  And I 
would want other, good, worthwhile updates too - not a cold stop at 1.0 
and no prospect of a 2.0.

-[Unknown]



 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message
 news:d87d35$2at4$1 digitaldaemon.com...
 

Just my opinion, though.  And, no, I'm not being so helpful as proposing
a solution.


 
 
 I know upgrades that require source code changes suck. But I hope you'll
 find that this one is worth it.
Jun 08 2005
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Unknown W. Brackets wrote:

 I didn't mean to imply it wasn't - and, in this time, while D is not yet 
 "stable" and has not reached 1.0, it's fine.  I don't mind the version 
 clashes one bit.
 
 It's after 1.0 that I will, should another occur at that time.  And I 
 would want other, good, worthwhile updates too - not a cold stop at 1.0 
 and no prospect of a 2.0.
 
 -[Unknown]
 

 I know upgrades that require source code changes suck. But I hope you'll
 find that this one is worth it.





Come on, we're in pre 1.0 time, such updates are really appreciated and 
should not be a problem. Walter, just add introspection/reflection to 
the language and I'll kill -9 everyone who doesn't switch to D ;)



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
"Tom S" <h3r3tic remove.mat.uni.torun.pl> wrote in message
news:d87qdq$2pe4$1 digitaldaemon.com...

 Come on, we're in pre 1.0 time, such updates are really appreciated and
 should not be a problem. Walter, just add introspection/reflection to
 the language and I'll kill -9 everyone who doesn't switch to D ;)


The is expressions are a big step in that direction.
Jun 08 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jun 2005 09:53:35 -0700, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:skmeququbanx$.a6mchwy1wg9c.dlg 40tude.net...

 Unless Walter provides a way, I will be forced into using a preprocessor


 to

 generate compilable source code for all the platforms I am hoping to
 support. This means I also have to make available multiple editions of the
 source files available so people can download the one(s) they need. Just
 plain stupidity!


 
 But that's the point of having the -d switch!
 
 And since compiler updates are free, there's no reason to support older
 versions once GDC gets updated.


Exactly! But in the meantime, do I just wait upon othes to all catch up.
Today we only have two compilers, but soon we could have many compilers? 

I really, really, really, really, would like a cost-effective solution to
this very real problem. This is not a stupid request. 

The -d switch is a *workaround*. And it only effects certain changes in
syntax and not all possible changes.

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:19:04 AM
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1t9a2kjsrkjbi.6xdppe5dta9d.dlg 40tude.net...

 Exactly! But in the meantime, do I just wait upon othes to all catch up.
 Today we only have two compilers, but soon we could have many compilers?

 I really, really, really, really, would like a cost-effective solution to
 this very real problem. This is not a stupid request.

 The -d switch is a *workaround*. And it only effects certain changes in
 syntax and not all possible changes.


I agree that -d is a workaround, and a transitional tool. But waiting for
the change to GDC should hopefully be a short one, and then -d won't be
needed, so a transitional workaround is acceptable. I think it is practical
to live with this for now, since we are pre-1.0 and there are only two
compilers out there. Post 1.0, and when there are more compilers with
varying update schedules, the use of predefined version identifiers will
become necessary.

BTW, the !is problem can also be worked around by using !(a is b). I wrote
upon introducing the iftype feature that it was experimental, so it
shouldn't have become embedded. The new inner classes should be backward
compatible with the old nested classes, except that they are now 4 bytes
larger. The only real problem, then, are the changes to the way associative
arrays work. The needed source code changes, though, are designed to be
obvious and should not be bugs waiting to happen. DMDScript uses associative
arrays heavilly, and I think just four spots in the code needed to be
altered, all of which were found at compile time.
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 8 Jun 2005 16:06:27 -0700, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:1t9a2kjsrkjbi.6xdppe5dta9d.dlg 40tude.net...

 Exactly! But in the meantime, do I just wait upon othes to all catch up.
 Today we only have two compilers, but soon we could have many compilers?

 I really, really, really, really, would like a cost-effective solution to
 this very real problem. This is not a stupid request.

 The -d switch is a *workaround*. And it only effects certain changes in
 syntax and not all possible changes.


 
 I agree that -d is a workaround, and a transitional tool. But waiting for
 the change to GDC should hopefully be a short one,


quote: "hopefully"  - but we don't know that do we? 


 and then -d won't be
 needed, so a transitional workaround is acceptable. I think it is practical
 to live with this for now, since we are pre-1.0 and there are only two
 compilers out there. Post 1.0, and when there are more compilers with
 varying update schedules, the use of predefined version identifiers will
 become necessary.


How could version identifiers solved the introduction of the '$' token?
 

 BTW, the !is problem can also be worked around by using !(a is b).


LOL.  Now that is spin!


-- 
Derek
Melbourne, Australia
9/06/2005 9:24:04 AM
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:w4m6gqts3i8p$.1375i9w9l94d2.dlg 40tude.net...

 I agree that -d is a workaround, and a transitional tool. But waiting




for

 the change to GDC should hopefully be a short one,


 quote: "hopefully"  - but we don't know that do we?


David Friedman has been very good with keeping GDC up to date.


 and then -d won't be
 needed, so a transitional workaround is acceptable. I think it is




practical

 to live with this for now, since we are pre-1.0 and there are only two
 compilers out there. Post 1.0, and when there are more compilers with
 varying update schedules, the use of predefined version identifiers will
 become necessary.


 How could version identifiers solved the introduction of the '$' token?


It wouldn't. It wouldn't work with non-syntactically valid code.
Jun 08 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 David Friedman has been very good with keeping GDC up to date.


I would second that one. David has been *exceptionally* good with
keeping his GDC in synch in with DMD while adding new (GDC-only)
features at the same time, as well as addressing minor old bugs...

Great work, both of you!

--anders
Jun 08 2005
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <trch1jhcb7pj.1qubpmdg2vvtf.dlg 40tude.net>, Derek Parnell says...

On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Ummm... I've got a problem ...

 void main()
 {
    Object x;
    
    version (DigitalMars)
    {
        if (x !is null) {}
    }
    else
    {
        if (x !== null) {}
    }
 }

I expected that by using the DigitalMars compiler that I wouldn't get ...

   "test.d(11): '!==' is deprecated, use '!is' instead"


Disappointing, but not unexpected for me.

It's not ideal, but doesn't this work for both the current DMD and the latest
GDC?
if (!(x is null))

I know it's a little cumbersome, but I think it'd be better than using a
preprocessor.

Hopefully, GDC will sync up with the current DMD pretty soon again since there
are so many significant changes in DMD 0.126.

jcc7
Jun 08 2005
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d85vju$so2$1 digitaldaemon.com...

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


very nice! The "is expression" looks like it'll be very useful.
Jun 08 2005
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
You're the man!

Really, I think it's amazing how fast you did full inner classes support 
(and even some other stuff)! Do you take apprentices? :)


xs0
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
"xs0" <xs0 xs0.com> wrote in message news:d86npf$1m4i$1 digitaldaemon.com...

 You're the man!

 Really, I think it's amazing how fast you did full inner classes support
 (and even some other stuff)! Do you take apprentices? :)


Actually, I implemented it 3 times before I figured out the right way to
install it. Nested classes are fairly similar to nested functions, so many
of the internal compiler issues had already been solved.
Jun 08 2005
prev sibling next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Why are stdin/stdout/stderr deprecated?
Is it recommended to use din/dout/derr instead?
Any way to keep the source compatible with GDC?
Jun 08 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"zwang" <nehzgnaw gmail.com> wrote in message 
news:d86t3v$1rf1$1 digitaldaemon.com...

 Why are stdin/stdout/stderr deprecated?


It seemed redundant to have two Stream interfaces to stdin/out and din/out 
mesh better with std.c.stdin/out. The downside is that din/out aren't 
std.stream.Files.


 Is it recommended to use din/dout/derr instead?


If one needs a Stream then use din/dout/derr.


 Any way to keep the source compatible with GDC?


Compile with -d to enable deprecated features, I guess.
Jun 08 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Ok. I've had some problems switching from iftype to static if 
(is(T:real)), but now I've come across something that really doesn't 
make any sense...

I've attached two files, and the question i ask is, why does test1.d 
fail to compile, while test2.d compiles, if the only difference between 
them is...

from test1.d...

          static if(is(T : real))
          {
             inta!(T)(dat);
          }
          else if(is(T : Object))
          {
             obj!(T)(dat);
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }

vs this from test2.d...

          static if(is(T : Object))
          {
             obj!(T)(dat);
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }

test1.d blurts out the compiler error, ...

test1.d(35): incompatible types for ((dat) === (null)): 'Point' and 'void*'
test1.d(36): cannot implicitly convert expression (new Point *) of type 
Point * to Point
test1.d(14): template instance temp.Foo.obj!(Point ) error instantiating
test1.d(18): function expected before (), not template instance 
str!(Point ) of type void
test1.d(70): template instance temp.Foo.bar!(Point ) error instantiating

Are you not allowed to use static if for multiple layers? I figured out 
I can fix it by using ...

          static if(is(T : real))
          {
             inta!(T)(dat);
          }
          static if(is(T : Object))
          {
             obj!(T)(dat);
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }

-clayasaurus
Jun 08 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
Both of them compile cleanly when I try it.
Jun 08 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter wrote:

 Both of them compile cleanly when I try it.
 
 


lol. ahh. i must have put the wrong files up. *smacks head*

here is the test1 that shouldn't compile...
Jun 08 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Here is the original that doesn't compile, and better shows what exactly 
I was trying to do.



clayasaurus wrote:

 Walter wrote:
 

 Both of them compile cleanly when I try it.


 
 lol. ahh. i must have put the wrong files up. *smacks head*
 
 here is the test1 that shouldn't compile...
 
 
 ------------------------------------------------------------------------
 
 module temp; 
 class Foo
 {
    template bar(T)
    {
       void bar(inout T dat)
       {
          static if(is(T : real))
          {
             inta!(T)(dat);  
          }
          if(is(T : Object))
          {
             obj!(T)(dat); 
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }
       }
    }
 
    template inta(T)
    {
       void inta(inout T dat)
       {
          dat = 3; 
       }
    }
 
    template obj(T)
    {
       void obj(inout T dat)
       {
          if (dat is null) // here lies the problem?
             dat = new T; 
          
       }
    }
 
    template str(T)
    {
       void str(inout T dat)
       {
       }
    }
 }
 
 
 struct Point
 {
    float x, y;
 
    void desc(Foo s)
    {
       s.bar!(float)(x);
       s.bar!(float)(y); 
    }
 }
 
 int main()
 {
    Point p;
    p.x = 3.14159; p.y = 1.41421;
 
    Foo foo = new Foo;
 
    foo.bar!(Point)(p); 
 
    return 0;
 }
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
Replace:
    "else if"
with:
    "else static if"
Jun 08 2005
parent clayasaurus <clayasaurus gmail.com> writes:
Walter wrote:

 Replace:
     "else if"
 with:
     "else static if"
 
 


thanks :-)
Jun 08 2005
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
Ok.. the 'fix' that I used is still broken. Here's what I have to do for 
it to compile...

          static if (is(T : real))
          {
             prim!(T)(dat);
          }

          static if (is(T : Object))
          {
             obj!(T)(dat);
          }

          static if (!is(T : Object) && !is(T : real))
          {
             str!(T)(dat);
          }

weird, no?


clayasaurus wrote:

 Walter wrote:
 

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 
 Ok. I've had some problems switching from iftype to static if 
 (is(T:real)), but now I've come across something that really doesn't 
 make any sense...
 
 I've attached two files, and the question i ask is, why does test1.d 
 fail to compile, while test2.d compiles, if the only difference between 
 them is...
 
 from test1.d...
 
          static if(is(T : real))
          {
             inta!(T)(dat);
          }
          else if(is(T : Object))
          {
             obj!(T)(dat);
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }
 
 vs this from test2.d...
 
          static if(is(T : Object))
          {
             obj!(T)(dat);
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }
 
 test1.d blurts out the compiler error, ...
 
 test1.d(35): incompatible types for ((dat) === (null)): 'Point' and 'void*'
 test1.d(36): cannot implicitly convert expression (new Point *) of type 
 Point * to Point
 test1.d(14): template instance temp.Foo.obj!(Point ) error instantiating
 test1.d(18): function expected before (), not template instance 
 str!(Point ) of type void
 test1.d(70): template instance temp.Foo.bar!(Point ) error instantiating
 
 Are you not allowed to use static if for multiple layers? I figured out 
 I can fix it by using ...
 
          static if(is(T : real))
          {
             inta!(T)(dat);
          }
          static if(is(T : Object))
          {
             obj!(T)(dat);
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }
 
 -clayasaurus
 
 
 ------------------------------------------------------------------------
 
 module temp; 
 class Foo
 {
    template bar(T)
    {
       void bar(inout T dat)
       {
          static if(is(T : real))
          {
             inta!(T)(dat);  
          }
          static if(is(T : Object))
          {
             obj!(T)(dat); 
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }
       }
    }
 
    template inta(T)
    {
       void inta(inout T dat)
       {
          dat = 3; 
       }
    }
 
    template obj(T)
    {
       void obj(inout T dat)
       {
          if (dat is null) // here lies the problem?
             dat = new T; 
          
       }
    }
 
    template str(T)
    {
       void str(inout T dat)
       {
       }
    }
 }
 
 
 struct Point
 {
    float x, y;
 
    void desc(Foo s)
    {
       s.bar!(float)(x);
       s.bar!(float)(y); 
    }
 }
 
 int main()
 {
    Point p;
    p.x = 3.14159; p.y = 1.41421;
 
    Foo foo = new Foo;
 
    
 
    foo.bar!(Point)(p); 
 
    return 0;
 }
 
 
 ------------------------------------------------------------------------
 
 module temp; 
 class Foo
 {
    template bar(T)
    {
       void bar(inout T dat)
       {
          static if(is(T : Object))
          {
             obj!(T)(dat); 
          }
          else // assume it is a struct
          {
             str!(T)(dat);
          }
       }
    }
 
    template inta(T)
    {
       void inta(inout T dat)
       {
          dat = 3; 
       }
    }
 
    template obj(T)
    {
       void obj(inout T dat)
       {
          if (dat is null) // here lies the problem?
             dat = new T; 
          
       }
    }
 
    template str(T)
    {
       void str(inout T dat)
       {
       }
    }
 }
 
 
 struct Point
 {
    float x, y;
 
    void desc(Foo s)
    {
       s.bar!(float)(x);
       s.bar!(float)(y); 
    }
 }
 
 int main()
 {
    Point p;
    p.x = 3.14159; p.y = 1.41421;
 
    Foo foo = new Foo;
 
    foo.bar!(Point)(p); 
 
    return 0;
 }
Jun 08 2005
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.this-is-spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter schrieb am Tue, 7 Jun 2005 22:17:50 -0700:

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


"!=0 means gag reporting of errors" 

now that's one of the best sourcecode documentations ever ;)



-----BEGIN PGP SIGNATURE-----

iD8DBQFCpzOR3w+/yD4P9tIRApeeAJ965VNqlrGF3XgIjLgoMYovQtJ01QCbBJNF
D9kl4tCyZaCCEvE0nF37LXU=
=8rlp
-----END PGP SIGNATURE-----
Jun 08 2005
parent reply Sean Kelly <sean f4.ca> writes:
Quick question about the documentation... in the docs for the 'is' expression:

alias int func(int);	// func is a alias to a function type

Shouldn't this be:

alias int function(int) func;	// func is a alias to a function type


Sean
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d87fqr$2du8$1 digitaldaemon.com...

 Quick question about the documentation... in the docs for the 'is'


expression:

 alias int func(int); // func is a alias to a function type

 Shouldn't this be:

 alias int function(int) func; // func is a alias to a function type


No, the latter declares func to be a *pointer* to a function type.
Jun 08 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
The following:

void sum(int[] ar ...)

In the documentation for the new typesafe variadic parameters... here:

http://www.digitalmars.com/d/function.html#variadic

Should probably read:

int sum(int[] ar ...)

No?

-[Unknown]



 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
Good catch. Fixed.
Jun 08 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Egads, how'd I miss this announcement?  It's like Christmas!  Quick question:
when "delete map[key]" goes away completely, will it begin to function like a
normal delete operation?  ie. will it delete the referenced class and set the
hashed value to null?


Sean
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d87ffi$2dac$1 digitaldaemon.com...

 Egads, how'd I miss this announcement?  It's like Christmas!  Quick


question:

 when "delete map[key]" goes away completely, will it begin to function


like a

 normal delete operation?  ie. will it delete the referenced class and set


the

 hashed value to null?


Yes.
Jun 08 2005
prev sibling next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <d85vju$so2$1 digitaldaemon.com>, Walter says...

Added inner classes.

http://www.digitalmars.com/d/changelog.html


WOW! You've been very busy Walter! Great Job!! :)

In the dmd v0.126 changlog it states: "delete aa[key] is now deprecated, use
aa.remove(key) instead." 

It's a little thing, but the D compiler doesn't throw a "deprecated" message for
code that's using the "delete aa[key]" as it should when the "-d" switch is not
being used. Just thought you should know.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"David L. Davis" <SpottedTiger yahoo.com> wrote in message
news:d87sok$2rff$1 digitaldaemon.com...

 In the dmd v0.126 changlog it states: "delete aa[key] is now deprecated,


use

 aa.remove(key) instead."

 It's a little thing, but the D compiler doesn't throw a "deprecated"


message for

 code that's using the "delete aa[key]" as it should when the "-d" switch


is not

 being used. Just thought you should know.


I thought it did, and in fact it has on my usages of delete aa[key].
Jun 08 2005
parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <d87tom$2sap$2 digitaldaemon.com>, Walter says...

"David L. Davis" <SpottedTiger yahoo.com> wrote in message
news:d87sok$2rff$1 digitaldaemon.com...

 In the dmd v0.126 changlog it states: "delete aa[key] is now deprecated,


use

 aa.remove(key) instead."

 It's a little thing, but the D compiler doesn't throw a "deprecated"


message for

 code that's using the "delete aa[key]" as it should when the "-d" switch


is not

 being used. Just thought you should know.


I thought it did, and in fact it has on my usages of delete aa[key].


Ok, "the proof is in the pudding." Here's the code I test compiled without an
error message... so either I misunderstood the changlog, or the version of dmd
v0.126 I've downloaded is different from yours. <g>








































































Output:
---------
C:\dmd>dmd
Digital Mars D Compiler v0.126
Copyright (c) 1999-2005 by Digital Mars written by Walter Bright
Documentation: www.digitalmars.com/d/index.html
Usage:
dmd files.d ... { -switch }

files.d        D source files
-c             do not link
-d             allow deprecated features
-debug         compile in debug code
-debug=level   compile in debug code <= level
-debug=ident   compile in debug code identified by ident
-g             add symbolic debug info
-Ipath         where to look for imports
-inline        do function inlining
-Llinkerflag   pass linkerflag to link
-O             optimize
-odobjdir      write object files to directory objdir
-offilename    name output file to filename
-op            do not strip paths from source file
-profile       profile runtime performance of generated code
-quiet         suppress unnecessary messages
-release       compile release version
-unittest      compile in unit tests
-v             verbose
-version=level compile in version code >= level
-version=ident compile in version code identified by ident
-w             enable warnings

C:\dmd>dmd assocarray.d
C:\dmd\bin\..\..\dm\bin\link.exe assocarray,,,user32+kernel32/noi;

C:\dmd>assocarray
With the associative array empty, does "key" exist? no

Now adding entries "key" and "key2"

The associative array now has 2 entries listed below.
sKey="key", sValue="added a key"
sKey="key2", sValue="added another key"

After adding the keys, does "key" exist? yes

Now removing "key2"...
After removing, does "key2" now exist? no
The associative array now has 1 entries.

Before ending display all remaining keys...
sKey="key", sValue="added a key"

C:\dmd>

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Jun 08 2005
parent "Walter" <newshound digitalmars.com> writes:
Darn, you're right. I can't explain it at the moment :-(
Jun 08 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


<quote>
Now throws an ArrayBoundsError if accessing an associative array with a 
key that is not already in the array. Previously, the key would be added 
to the array.
</quote>
Execuse my n00bness, but how do you add keys to the associative array then?
Jun 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 08 Jun 2005 18:00:15 -0600, Hasan Aljudy wrote:


 Walter wrote:

 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html
 


 
 <quote>
 Now throws an ArrayBoundsError if accessing an associative array with a 
 key that is not already in the array. Previously, the key would be added 
 to the array.
 </quote>
 Execuse my n00bness, but how do you add keys to the associative array then?


int[char[]] arr;

  arr["these"] = 1;
  arr["are"] = 3;
  arr["new"] = 6;
  arr["keys"] = 2;

In previous versions, the line below would have automatically added the key
"not here" to the array  ...

  if (arr["not here"]) { . . .}


-- 
Derek
Melbourne, Australia
9/06/2005 10:27:10 AM
Jun 08 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 <quote>
 Now throws an ArrayBoundsError if accessing an associative array with a
 key that is not already in the array. Previously, the key would be added
 to the array.
 </quote>
 Execuse my n00bness, but how do you add keys to the associative array 
 then?


 int[char[]] arr;

  arr["these"] = 1;
  arr["are"] = 3;
  arr["new"] = 6;
  arr["keys"] = 2;


I'm happy to see Walter was able to also keep the samples/d/wc2.d style of 
adding when used in an lvalue operator like ++. The word-count code uses 
dictionary[word]++ to insert if not present.
Jun 08 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d88733$1t9$1 digitaldaemon.com...

 I'm happy to see Walter was able to also keep the samples/d/wc2.d style of
 adding when used in an lvalue operator like ++. The word-count code uses
 dictionary[word]++ to insert if not present.


Yeah, it was important to keep that one!
Jun 08 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <d88733$1t9$1 digitaldaemon.com>, Ben Hinkle says...

 <quote>
 Now throws an ArrayBoundsError if accessing an associative array with a
 key that is not already in the array. Previously, the key would be added
 to the array.
 </quote>
 Execuse my n00bness, but how do you add keys to the associative array 
 then?


 int[char[]] arr;

  arr["these"] = 1;
  arr["are"] = 3;
  arr["new"] = 6;
  arr["keys"] = 2;


I'm happy to see Walter was able to also keep the samples/d/wc2.d style of 
adding when used in an lvalue operator like ++. The word-count code uses 
dictionary[word]++ to insert if not present. 


So insertion just doesn't occur when the AA is treated as an rvalue?  This is
good news.  I was worried we wouldn't be able to do this.


Sean
Jun 09 2005
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:

 On Wed, 08 Jun 2005 18:00:15 -0600, Hasan Aljudy wrote:
 

<quote>
Now throws an ArrayBoundsError if accessing an associative array with a 
key that is not already in the array. Previously, the key would be added 
to the array.
</quote>
Execuse my n00bness, but how do you add keys to the associative array then?


 
 
 int[char[]] arr;
 
   arr["these"] = 1;
   arr["are"] = 3;
   arr["new"] = 6;
   arr["keys"] = 2;
 
 In previous versions, the line below would have automatically added the key
 "not here" to the array  ...
 
   if (arr["not here"]) { . . .}
 
 


This is kinda confusing ..

 From a compiler's point of view, what's the difference between these lines:

arr["key"] = value;
value = arr["key"];
arr["key"];
if( arr["key"] ) { /+ code +/ }


What makes the compiler handle them differently?
I can see in the first line, arr["key"] is an lvalue, while in the 
second it's an rvalue .. but why would the first one create "key" and 
not the second one. I believe that in both cases you would attempt to 
find a reference to arr["key"] first, then do stuff with it.

And, what about this example:
arr["key"] = arr["key"];
or this:
arr["key"] = arr["key"] + 1;

What would happen if the key "key" didn't exist? would it be created as in
arr["key"] = value;
or would it cause an error as in
if( arr["key"] ) ...


I don't really care if the questions were answered ..
I just wanted to point out the confusion.

Why shouldn't arr["key"] create the key "key"?

I guess this was mainly done to avoid creating a new key when the user 
only wants to check if it existed
if( arr["key"] ) //shouldn't create the key "key"
but isn't this solved with the "in" keyword? so the above line becomes 
deprecated, and the new way is:
if( "key" in arr )
Jun 09 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Hasan Aljudy wrote:
<snip>

 And, what about this example:
 arr["key"] = arr["key"];
 or this:
 arr["key"] = arr["key"] + 1;
 
 What would happen if the key "key" didn't exist? would it be created as in
 arr["key"] = value;
 or would it cause an error as in
 if( arr["key"] ) ...


The latter.  The rvalue is evaluated and then assigned to the lvalue. 
So at the point when the rvalue is evaluated,


 I don't really care if the questions were answered ..
 I just wanted to point out the confusion.
 
 Why shouldn't arr["key"] create the key "key"?
 
 I guess this was mainly done to avoid creating a new key when the user 
 only wants to check if it existed
 if( arr["key"] ) //shouldn't create the key "key"
 but isn't this solved with the "in" keyword? so the above line becomes 
 deprecated, and the new way is:
 if( "key" in arr )


No, that has always been the way.

The two statements had different meanings then and have different 
meanings now.

Previously,

     if (arr["key"])

would succeed if the value of arr["key"] has a 'true' boolean 
interpretation.  If arr["key"] doesn't exist prior to the lookup, it 
would succeed if the value type's .init has a 'true' boolean 
interpretation.  At least that's the way it was supposed to behave - 
there seems to be a bug as I test it in GDC 0.11.

On the other hand,

     if ("key" in arr)

succeeds iff the key is present in the AA.

Now,

     if (arr["key"])

would have the same effect if the key is in, or throw an 
ArrayBoundsError if it isn't.  OTOH,

     if ("key" in arr)

behaves in the same way as it did before.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 09 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d85vju$so2$1 digitaldaemon.com...

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


This is the single most amazing patch I've seen since I found D!

Woot!
Jun 08 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d886vk$1rt$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d85vju$so2$1 digitaldaemon.com...

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 This is the single most amazing patch I've seen since I found D!

 Woot!


Ooh!  I just had an idea: nested class inheritance in inherited outer 
classes.

I like how classes inherit nested classes from parent classes.  But how 
about this:

class A
{
 class B
 {

 }
}

class C : A
{
 class D : A.B
 {

 }
}


This is illegal because B is not in C's scope, even though C has access to 
B.

How about making it legal?  Or would that just make things too complicated?
Jun 08 2005
parent reply "Walter" <newshound digitalmars.com> writes:
AAIIIIEEEEEEE !!!!!!
Jun 08 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d88dou$961$3 digitaldaemon.com...

 AAIIIIEEEEEEE !!!!!!


Lol, I take it that's a "no" ;)
Jun 09 2005
parent "Walter" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:d8991r$18gi$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d88dou$961$3 digitaldaemon.com...

 AAIIIIEEEEEEE !!!!!!


 Lol, I take it that's a "no" ;)


I prefer to say "no" to such things unless there is a demonstrable need for
it and no easy alternative. Kris was able to demonstrate that for inner
classes, so in they went.
Jun 09 2005
prev sibling parent reply zwang <nehzgnaw gmail.com> writes:
Jarrett Billingsley wrote:

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d85vju$so2$1 digitaldaemon.com...
 

Added inner classes.

http://www.digitalmars.com/d/changelog.html


 
 
 This is the single most amazing patch I've seen since I found D!
 
 Woot! 
 
 


I was actually using all the now deprecated features.
Guess how painful it was to upgrade to dmd 0.126.
Walter, could you please *not* roll out too many major changes in one release?
Jun 08 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
zwang wrote:


 This is the single most amazing patch I've seen since I found D!

 Woot!


 
 I was actually using all the now deprecated features.


Why not just add the -d flag in the meantime ?


 Guess how painful it was to upgrade to dmd 0.126.


Try adding the -w flag, for some extra salt :-)


 Walter, could you please *not* roll out too many major changes in one 
 release?


You're not trying to stop progress, are you ?

--anders
Jun 09 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 I was actually using all the now deprecated features.
 Guess how painful it was to upgrade to dmd 0.126.
 Walter, could you please *not* roll out too many major changes in one 
 release?


I actually prefer upgrading my code once rather than strung out over several 
releases. I've been upgrading to 126 and the error messages make it obvious 
what has changed so it isn't that bad IMO.
Jun 09 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.
 
 http://www.digitalmars.com/d/changelog.html


Is there a reason for cstream.d having public imports? I think private ones
will cause less potential hiccups.

-- 
Derek
Melbourne, Australia
9/06/2005 3:48:30 PM
Jun 08 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1he6yst5qhjp2.9hzslvyydu8u$.dlg 40tude.net...

 On Tue, 7 Jun 2005 22:17:50 -0700, Walter wrote:


 Added inner classes.

 http://www.digitalmars.com/d/changelog.html


 Is there a reason for cstream.d having public imports? I think private 
 ones
 will cause less potential hiccups.


Since cstream is designed to make mixing std.c.stdio and std.stream easy any 
hiccup should preferrably be fixed rather than avoided. The behavior is 
similar to how std.stdio publically imports std.c.stdio. Are there any 
issues in particular you are worried about?
Jun 09 2005
prev sibling next sibling parent derick_eddington nospam.yashmoo.com writes:
IsExpression rules! Typesafe variadic functions are great! Thanks, Walter!

In article <d85vju$so2$1 digitaldaemon.com>, Walter says...

Added inner classes.

http://www.digitalmars.com/d/changelog.html
Jun 09 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Quick question about remove() since I can't test the new release quite yet.
Does it return the stored value?  It would be nice if we could do things like
this:

int[int] a;
Objecct[int] b;
printf( "removed %i\n", a.remove(1) );
delete b.remove(2);

I grant that the syntax is a bit odd for the delete line, but it saves a double
lookup or the need to add a second function for the purpos (erase?).


Sean
Jun 09 2005
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d89ok7$1pdb$1 digitaldaemon.com...

 Quick question about remove() since I can't test the new release quite


yet.

 Does it return the stored value?  It would be nice if we could do things


like

 this:

 int[int] a;
 Objecct[int] b;
 printf( "removed %i\n", a.remove(1) );
 delete b.remove(2);

 I grant that the syntax is a bit odd for the delete line, but it saves a


double

 lookup or the need to add a second function for the purpos (erase?).


Currently, it returns a void.
Jun 09 2005
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
Two thumbs up!

-Craig

"Walter" <newshound digitalmars.com> wrote in message 
news:d85vju$so2$1 digitaldaemon.com...

 Added inner classes.

 http://www.digitalmars.com/d/changelog.html
Jun 09 2005
prev sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <d85vju$so2$1 digitaldaemon.com>, Walter says...

Added inner classes.

http://www.digitalmars.com/d/changelog.html


Walter, the following D code now skips on passing in a char[] literal into a
function that has both a func(in char[]) and a func(in char *) defined. Is this
a new change in D's behavior in handling string literals? Or is this a
side-effect / error from the current v0.126 changes?























Output:
--------
C:\dmd>dmd overlord.d
overlord.d(8): function overlord.printValue called with argument types:
(char[14])
matches both:
overlord.printValue(char[])
and:
overlord.printValue(char*)

C:\dmd>

Thanks in advance for your reply,
David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Jun 09 2005
parent "Walter" <newshound digitalmars.com> writes:
"David L. Davis" <SpottedTiger yahoo.com> wrote in message
news:d89qub$1rno$1 digitaldaemon.com...

 Walter, the following D code now skips on passing in a char[] literal into


a

 function that has both a func(in char[]) and a func(in char *) defined. Is


this

 a new change in D's behavior in handling string literals? Or is this a
 side-effect / error from the current v0.126 changes?























 Output:
 --------
 C:\dmd>dmd overlord.d
 overlord.d(8): function overlord.printValue called with argument types:
 (char[14])
 matches both:
 overlord.printValue(char[])
 and:
 overlord.printValue(char*)


It's intentional, as a string literal is implicitly convertible to either
char[] or char*.
Jun 09 2005