June 09, 2005 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | >> <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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | "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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | "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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David L. Davis | Darn, you're right. I can't explain it at the moment :-( |
June 09, 2005 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | "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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | AAIIIIEEEEEEE !!!!!! |
June 09, 2005 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | 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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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 Re: DMD 0.126 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Unknown W. Brackets | 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 |
Copyright © 1999-2021 by the D Language Foundation