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

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

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

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

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

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

"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].

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

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.

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