June 09, 2005
>> <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.


June 09, 2005
"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?


June 09, 2005
"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.


June 09, 2005
Darn, you're right. I can't explain it at the moment :-(


June 09, 2005
"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!


June 09, 2005
AAIIIIEEEEEEE !!!!!!


June 09, 2005
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
June 09, 2005
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 ;-)
> 
June 09, 2005
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.

















June 09, 2005
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