*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.
> 

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

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?

In article <d88f6c$br5$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>Don't forget comments!
>
>-[Unknown]

Yep. Comments, too.

jcc7

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

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

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

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?
> 

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
>
>
>

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 )