Walter wrote:

> A C++ reference parameter gives no clue whether it is in, out, or inout. The
> situation is such that Microsoft went ahead and invented IDL (Interface
> Description Language), the sole point of which is to add that missing bit of
> information. IDL is irrelevant for D.

I prefer the "in/out" parameters. Reminds me of Ada or something...

> As has been debated here many times <g>, const as a type modifier in C++ is
> so semantically weak it is fairly useless. (Many disagree.) C and C++ are
> the only languages I've ever heard of that use const as a type modifier.
> Java and C# show no signs of adopting it. The C++ community has not
> convinced the larger programmer community that const as a type modifier has
> a place.

The only place for "const" seems to be protecting read-only attribute ?

> I'd argue that C++ is less complete, since it relies so heavilly on STL to
> do things that are built in to most languages. Doing a general purpose
> foreach with C++ is fiendishly difficult. It's for free in D.

I think I'll just let you fight that one out with Matthew ;-)
I never liked C++, so I went straight to Java. D changes that.

--anders

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0h20f$1r88$1@digitaldaemon.com...
>
> "Anders F Björklund" <afb@algonet.se> wrote in message
news:d0gu9k$1n20$2@digitaldaemon.com...
> > Walter wrote:
> >> As a *language*, what does C++ have over D?
> >> Implicit function template instantiation. It's hard to find much else.
>
>     const

Discussed in great depth elsewhere!

>     references

See my response to Anders on that.

>     bool

I'm not seeing it, Matthew!

>     namespaces

I really see nothing in C++ namespaces that has anything over D modules. Namespaces are a failed attempt to add module like semantics to C++, and I say failed because several experts told me that exported templates were needed in order to provide "coding hygiene", i.e. prevent the names in one source file from stepping on those in another. I found that interesting because that was exactly the problem that namespace was supposed to solve.

>     compile-time testing (none of that hideous runtime generic comparison
filth)

?? D has static asserts.

>     TMP

??

>     macro pre-processor

You can use the C preprocessor with D, if you want.

>     'using'

Replaced with 'alias'.

>     operators that look like operators

Sorry, but that's a bug in C++.

>     compilers that warn

Thrashed that one to death <g>.

>     proper cast operators,

I know there's a thread on that, but I haven't gotten to it yet.

> and the ability to fill the gaps in the spectrum with user defined types

?? D has full UDT support.

>     support for shims (implicit template instantiation coupled with
ability to manipulate names in global/specific
> namespaces)

Agreed.

>     lack of GC

Lack of GC is a feature? How? One can program D just like you can in C, strictly using malloc/free. Nary a GC object. D does not require GC.

>     ability to produce extremely small applications (i.e. supports
extremely low coupling, and allows one to dispense
> with C/C++ Runtime Library)

Phobos is a part of D, just like the C/C++ runtime library is a part of C/C++. In both languages, you can stub out what you don't want, or provide some minimal alternative. Phobos is certainly not a VM that must be dragged around for the trivialest apps.


>     etc. etc. etc.

? ? ?

> (For the record, I'm writing std.openrj right now, in 100% D, and enjoying
it for the most part. But it is *not* > unalloyed tra-la-la-ing in wonderland ...)

I predict that once you write enough D code, you'll discover that C++ is the incomplete language <g>. Try supporting UTF in the C++ version of openrj.

"Anders F Björklund" <afb@algonet.se> wrote in message news:d0hu4o$2orp$1@digitaldaemon.com...
> The only place for "const" seems to be protecting read-only attribute ?

I like "const" as meaning it really is constant. Read-only is a side effect of that. C++ const stuff may be read only, but it isn't constant. Other threads, and other references to the same data can change it at any time, which is why the C++ const is overrated.

>> simplified const handling (storage instead of type),
>
> As has been debated here many times <g>, const as a type modifier in C++ is so semantically weak it is fairly useless. (Many disagree.)

This is hugely disingenuous. _You_ don't think const has any use. But then _you_ don't use const. Maybe they're related?

I find const *enormously* useful, both for its intended uses and for the unforeseen tricks one can put it to. The absence of such is the largest common failing in other languages that I use, including C, Java, .NET *and* D, and a significant part of the reason why I don't tend to use those languages for serious development.

>C and C++ are
> the only languages I've ever heard of that use const as a type modifier. Java and C# show no signs of adopting it. The C++ community has not convinced the larger programmer community that const as a type modifier has a place.

How can you conclude that? One might just as well surmise that the implementation complexity is what deters these other 'communities'. After all, these other languages - Java, .NET, D - are all far more allied to specific vendors, and are therefore far more likely to be swayed by what's good for the vendor rather than what's good for the programmer.

That you don't recognise/acknowledge this shows that either you're trying to hoodwink us, or that you've succeeded too well in hoodwinking yourself.

> I'd argue that C++ is less complete, since it relies so heavilly on STL to do things that are built in to most languages. Doing a general purpose foreach with C++ is fiendishly difficult. It's for free in D.

As a general point, I must observe that you are far too prone these days to counter criticisms of D's feature X by saying feature Y is great. This is just stupid.

Yes, D has many marvellous features. This is a big part of why I am excited about D, and why I've stuck with it these last 2.5 years.

But D also has some serious flaws, omissions, and howling stinkers.

The absence of some/all of const in D is a flaw. Period! The only debate is where the some/all point is drawn. To
counter
by saying that Java and .NET haven't followed C++ is (i) not true, and (ii) disingenuous. IIRC, Java does use final on
members, so one of the *fabulous powers of const in C++* has been aped. That D has not followed this particular facet
is a manifest flaw, and cannot be explained away by 'the complexity of using/implementing const'. It's nothing more than
an extension of your personal uninformed (since you don't use const) prejudices.

So, Walter, I say stop telling us about the great things in D. We all know and love them. No other language I know of can do slices, and the combination of slices, GC and auto is unparalleled. (FGI: Walter and I are doing an article on this "Not Your Father's Resource Management" for DDJ just as soon as I get my fingers out of all the other pies and do my half of it. The article shows how D is an optimal mix of C++'s and Java/.NET's resource management paradigms, and is superior to them all.)

What's going to stop D prospering is not failure-to-recognise-its-many-significant-virtues, but all-too-ready-recognition-of-its-many-significant-flaws.

Sheesh! If I went to a psychologist to get help in sorting out my many personality flaws, I wouldn't waste her time and my money in long and fatuous discussions about my many admirable traits!!!

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0idln$97o$1@digitaldaemon.com...
> >> simplified const handling (storage instead of type),
> > As has been debated here many times <g>, const as a type modifier in C++
is
> > so semantically weak it is fairly useless. (Many disagree.)
> This is hugely disingenuous. _You_ don't think const has any use.

Right - many disagree - and I was thinking specifically of you!

> But then _you_ don't use const. Maybe they're related?

I used to use const as a type modifier. I gave it up after becoming disenchanted with it. I use const as a storage class all the time. (The two uses are very different,  although they look the same in C++. I wish to emphasize the difference, as sometimes in these threads they incorrectly get referred to interchangeably.)

> That you don't recognise/acknowledge this shows that either you're trying
to hoodwink us, or that you've succeeded too
> well in hoodwinking yourself.

I understand that you made a convincing argument. I respectfully suggest, however, that doesn't necessarilly mean I was convinced and am therefore trying to argue things I secretly believe to be false.

I know exactly how to implement const as a type modifier. If I believed it was the right thing to do, I'd do it. Microsoft and Sun both have inhouse C++ compilers under active development, and they know how to do it, too. They've both poured incredible resources in developing C# and Java. I have no idea exactly how the decision came about not to use const as a type modifier (as distinct from const as a storage class), but you can bet your last dollar that if they felt it had high value, it'd be implemented. This is one reason why I don't think I am way out of step in my opinion on const as a type modifier.

> > I'd argue that C++ is less complete, since it relies so heavilly on STL
to
> > do things that are built in to most languages. Doing a general purpose foreach with C++ is fiendishly difficult. It's for free in D.
> As a general point, I must observe that you are far too prone these days
to counter criticisms of D's feature X by
> saying feature Y is great. This is just stupid.

The thread is about whether C++ and D are "complete" languages or not, and I wrote that comment should in that context.

> The absence of some/all of const in D is a flaw. Period! The only debate
is where the some/all point is drawn. To
> counter
> by saying that Java and .NET haven't followed C++ is (i) not true, and
(ii) disingenuous. IIRC, Java does use final on
> members, so one of the *fabulous powers of const in C++* has been aped.
That D has not followed this particular facet
> is a manifest flaw, and cannot be explained away by 'the complexity of
using/implementing const'.

Java's 'final' is a storage class, not a type modifier. Its use on a field does not require the constructor to have an initializer for it. In fact, it is illegal to set 'final' fields inside a constructor. The initializer for the 'final' field must appear immediately after the declaration of the field, outside of any constructor. Therefore, constructor parameters cannot influence the setting of 'final' fields. Also, if one has multiple constructors in Java, and one 'forgets' to initialize one of the fields, no diagnostic is issued. The field gets default initialized. I'd argue it is a fairly different beast in Java than in C++, since it is not aping the C++ feature of getting diagnostics from the constructor about uninitialized const fields.

What Java's 'final' does share with C++ const fields is that the compiler will diagnose attempts to modify the field after it is set. Java did it right, though, as Java doesn't allow casting away of constness, or non-const references to the same field modifying it out from under you. 'final' fields in Java are solid enough that the compiler can optimize based on it, and they have meaning in multithreaded apps, which is not the case in C++.

I have no issue with const and final as a storage class, I believe they are valuable and useful, and const is implemented as a storage class in D (its use could probably be profitably extended to more contexts). I don't agree with its value as a type modifier, for oft stated reasons that I will summarize as being that in legal, standard conforming C++ code the value of the presumably 'const' data can change at any moment. Const things ought to be, dagnamit, constant.

Amen.

It's exactly this kind of thing that has so often worn me down to the bone [and why my sometimes inappropriate commentary joins the party; for which I do apologize]

I believe we should understand that D belongs to all of us. Everyone who has contributed in one form or another (through adopted ideas, through NG posts, through being a D evangelist, through writing supporting libraries, through examples, tutorials, and wiki's, through providing supporting web-services such as dsource.org and this NG, etc. etc.) *own* a piece of D. I don't think Walter could, or would, claim that D is his own thing at this time (in fact, our combined little bits of ownership probably amount to something rather significant).

As such, we kinda' owe it to ourselves to ensure the development of "our" language is 'managed' more effectively. After all, D requires a grass-roots approach to language adoption (in contrast to the marketing and financial clout of a .NET approach); it's people like us who will ultimately push for adoption of D within our own spheres of influence.


I'm noting this for three reasons:

1) you should realize that D is /your/ language ~ not someone else's. It will become mainstream not when D matures per se, but when each and all of us urge our development groups to consider adopting it. Walter has never spelt this out, but he's fully dependent upon each of us for the success of D (unless it's perhaps just a jolly wheeze instead).

When I see people talking about "Walter's language" it suggests either "Walter is a shallow and hollow individual" or "I can't personally accept the responsibility for making this better". There's probably plenty of room between, but you get the drift? We, each of us, is expected to do the hard work of local adoption. So we should get used to the ownership idea.

2) we deserve, and should expect more in terms of a transparent development process. Right now, it's almost completely opaque (save for the rare and occasional glimmer of a proactive request, such as the recent "$ or length?" topic initiated by Walter himself). I mean, at this point, a rational and constructive discourse over how to improve D in specific areas is the exception, rather than the norm. Instead, what's attached below typifies the reaction. This is surely a bad sign, and it is something that (IMO) Walter should reflect heavily upon.

3) Historically, there's been a lot of talk with very little action. For example, people have often lamented over the weaknesses of the D libraries. However, how many of you are willing to do something about changing that? We've got to take some responsibility ourselves to change things; be a bit more constructive and a lot more cooperative. Talk is cheap. There are perhaps one or two dozen people who are /really/ trying to contribute to D in this particular manner ... they can always use a bit of help! If you want good libraries for D, write them yourselves, or better, get some momentum going with others via the Ares project (over at dsource).

Something to think about.

- Kris


(p.s. please forgive me for hijacking your post, Matthew; but for a moment there you sounded just like me)



In article <d0idln$97o$1@digitaldaemon.com>, Matthew says...
>
>>> simplified const handling (storage instead of type),
>>
>> As has been debated here many times <g>, const as a type modifier in C++ is so semantically weak it is fairly useless. (Many disagree.)
>
>This is hugely disingenuous. _You_ don't think const has any use. But then _you_ don't use const. Maybe they're related?
>
>I find const *enormously* useful, both for its intended uses and for the unforeseen tricks one can put it to. The absence of such is the largest common failing in other languages that I use, including C, Java, .NET *and* D, and a significant part of the reason why I don't tend to use those languages for serious development.
>
>>C and C++ are
>> the only languages I've ever heard of that use const as a type modifier. Java and C# show no signs of adopting it. The C++ community has not convinced the larger programmer community that const as a type modifier has a place.
>
>How can you conclude that? One might just as well surmise that the implementation complexity is what deters these other 'communities'. After all, these other languages - Java, .NET, D - are all far more allied to specific vendors, and are therefore far more likely to be swayed by what's good for the vendor rather than what's good for the programmer.
>
>That you don't recognise/acknowledge this shows that either you're trying to hoodwink us, or that you've succeeded too well in hoodwinking yourself.
>
>> I'd argue that C++ is less complete, since it relies so heavilly on STL to do things that are built in to most languages. Doing a general purpose foreach with C++ is fiendishly difficult. It's for free in D.
>
>As a general point, I must observe that you are far too prone these days to counter criticisms of D's feature X by saying feature Y is great. This is just stupid.
>
>Yes, D has many marvellous features. This is a big part of why I am excited about D, and why I've stuck with it these last 2.5 years.
>
>But D also has some serious flaws, omissions, and howling stinkers.
>
>The absence of some/all of const in D is a flaw. Period! The only debate is where the some/all point is drawn. To
>counter
>by saying that Java and .NET haven't followed C++ is (i) not true, and (ii) disingenuous. IIRC, Java does use final on
>members, so one of the *fabulous powers of const in C++* has been aped. That D has not followed this particular facet
>is a manifest flaw, and cannot be explained away by 'the complexity of using/implementing const'. It's nothing more than
>an extension of your personal uninformed (since you don't use const) prejudices.
>
>So, Walter, I say stop telling us about the great things in D. We all know and love them. No other language I know of can do slices, and the combination of slices, GC and auto is unparalleled. (FGI: Walter and I are doing an article on this "Not Your Father's Resource Management" for DDJ just as soon as I get my fingers out of all the other pies and do my half of it. The article shows how D is an optimal mix of C++'s and Java/.NET's resource management paradigms, and is superior to them all.)
>
>What's going to stop D prospering is not failure-to-recognise-its-many-significant-virtues, but all-too-ready-recognition-of-its-many-significant-flaws.
>
>Sheesh! If I went to a psychologist to get help in sorting out my many personality flaws, I wouldn't waste her time and my money in long and fatuous discussions about my many admirable traits!!!
>
>
>
>

In article <d0iiqi$emd$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0idln$97o$1@digitaldaemon.com...
>> >> simplified const handling (storage instead of type),
>> > As has been debated here many times <g>, const as a type modifier in C++
>is
>> > so semantically weak it is fairly useless. (Many disagree.)
>> This is hugely disingenuous. _You_ don't think const has any use.
>
>Right - many disagree - and I was thinking specifically of you!
>
>> But then _you_ don't use const. Maybe they're related?
>
>I used to use const as a type modifier. I gave it up after becoming disenchanted with it. I use const as a storage class all the time. (The two uses are very different,  although they look the same in C++. I wish to emphasize the difference, as sometimes in these threads they incorrectly get referred to interchangeably.)
>
>> That you don't recognise/acknowledge this shows that either you're trying
>to hoodwink us, or that you've succeeded too
>> well in hoodwinking yourself.
>
>I understand that you made a convincing argument. I respectfully suggest, however, that doesn't necessarilly mean I was convinced and am therefore trying to argue things I secretly believe to be false.
>
>I know exactly how to implement const as a type modifier. If I believed it was the right thing to do, I'd do it. Microsoft and Sun both have inhouse C++ compilers under active development, and they know how to do it, too. They've both poured incredible resources in developing C# and Java. I have no idea exactly how the decision came about not to use const as a type modifier (as distinct from const as a storage class), but you can bet your last dollar that if they felt it had high value, it'd be implemented. This is one reason why I don't think I am way out of step in my opinion on const as a type modifier.
>
>> > I'd argue that C++ is less complete, since it relies so heavilly on STL
>to
>> > do things that are built in to most languages. Doing a general purpose foreach with C++ is fiendishly difficult. It's for free in D.
>> As a general point, I must observe that you are far too prone these days
>to counter criticisms of D's feature X by
>> saying feature Y is great. This is just stupid.
>
>The thread is about whether C++ and D are "complete" languages or not, and I wrote that comment should in that context.
>
>> The absence of some/all of const in D is a flaw. Period! The only debate
>is where the some/all point is drawn. To
>> counter
>> by saying that Java and .NET haven't followed C++ is (i) not true, and
>(ii) disingenuous. IIRC, Java does use final on
>> members, so one of the *fabulous powers of const in C++* has been aped.
>That D has not followed this particular facet
>> is a manifest flaw, and cannot be explained away by 'the complexity of
>using/implementing const'.
>
>Java's 'final' is a storage class, not a type modifier. Its use on a field does not require the constructor to have an initializer for it. In fact, it is illegal to set 'final' fields inside a constructor. The initializer for the 'final' field must appear immediately after the declaration of the field, outside of any constructor. Therefore, constructor parameters cannot influence the setting of 'final' fields. Also, if one has multiple constructors in Java, and one 'forgets' to initialize one of the fields, no diagnostic is issued. The field gets default initialized. I'd argue it is a fairly different beast in Java than in C++, since it is not aping the C++ feature of getting diagnostics from the constructor about uninitialized const fields.
>
>What Java's 'final' does share with C++ const fields is that the compiler will diagnose attempts to modify the field after it is set. Java did it right, though, as Java doesn't allow casting away of constness, or non-const references to the same field modifying it out from under you. 'final' fields in Java are solid enough that the compiler can optimize based on it, and they have meaning in multithreaded apps, which is not the case in C++.
>
>I have no issue with const and final as a storage class, I believe they are valuable and useful, and const is implemented as a storage class in D (its use could probably be profitably extended to more contexts). I don't agree with its value as a type modifier, for oft stated reasons that I will summarize as being that in legal, standard conforming C++ code the value of the presumably 'const' data can change at any moment. Const things ought to be, dagnamit, constant.


Very glad to hear you opinion on this. I, for one, agree 100%.

If you could provide a D mechanism for making scalar and vector data "appear" to be fully constant (as in the storage class) to third-parties (think return values), then we'd have the read-only enforcement so many of us are crying out for. That could easily become a major advantage for D over other languages.

In addition, the utility of a true storage-constant attribute (one that is also supported via call-by-reference ~ inout obviously does not work) then that would open up additional avenues for D.

On Mon, 7 Mar 2005 13:44:43 -0800, Walter wrote:

> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0idln$97o$1@digitaldaemon.com...
>>>> simplified const handling (storage instead of type),
>>> As has been debated here many times <g>, const as a type modifier in C++
> is
>>> so semantically weak it is fairly useless. (Many disagree.)
>> This is hugely disingenuous. _You_ don't think const has any use.
> 
> Right - many disagree - and I was thinking specifically of you!
> 
>> But then _you_ don't use const. Maybe they're related?
> 
> I used to use const as a type modifier. I gave it up after becoming disenchanted with it. I use const as a storage class all the time. (The two uses are very different,  although they look the same in C++. I wish to emphasize the difference, as sometimes in these threads they incorrectly get referred to interchangeably.)
> 
>> That you don't recognise/acknowledge this shows that either you're trying
> to hoodwink us, or that you've succeeded too
>> well in hoodwinking yourself.
> 
> I understand that you made a convincing argument. I respectfully suggest, however, that doesn't necessarilly mean I was convinced and am therefore trying to argue things I secretly believe to be false.
> 
> I know exactly how to implement const as a type modifier. If I believed it was the right thing to do, I'd do it. Microsoft and Sun both have inhouse C++ compilers under active development, and they know how to do it, too. They've both poured incredible resources in developing C# and Java. I have no idea exactly how the decision came about not to use const as a type modifier (as distinct from const as a storage class), but you can bet your last dollar that if they felt it had high value, it'd be implemented. This is one reason why I don't think I am way out of step in my opinion on const as a type modifier.
> 
>>> I'd argue that C++ is less complete, since it relies so heavilly on STL
> to
>>> do things that are built in to most languages. Doing a general purpose foreach with C++ is fiendishly difficult. It's for free in D.
>> As a general point, I must observe that you are far too prone these days
> to counter criticisms of D's feature X by
>> saying feature Y is great. This is just stupid.
> 
> The thread is about whether C++ and D are "complete" languages or not, and I wrote that comment should in that context.
> 
>> The absence of some/all of const in D is a flaw. Period! The only debate
> is where the some/all point is drawn. To
>> counter
>> by saying that Java and .NET haven't followed C++ is (i) not true, and
> (ii) disingenuous. IIRC, Java does use final on
>> members, so one of the *fabulous powers of const in C++* has been aped.
> That D has not followed this particular facet
>> is a manifest flaw, and cannot be explained away by 'the complexity of
> using/implementing const'.
> 
> Java's 'final' is a storage class, not a type modifier. Its use on a field does not require the constructor to have an initializer for it. In fact, it is illegal to set 'final' fields inside a constructor. The initializer for the 'final' field must appear immediately after the declaration of the field, outside of any constructor. Therefore, constructor parameters cannot influence the setting of 'final' fields. Also, if one has multiple constructors in Java, and one 'forgets' to initialize one of the fields, no diagnostic is issued. The field gets default initialized. I'd argue it is a fairly different beast in Java than in C++, since it is not aping the C++ feature of getting diagnostics from the constructor about uninitialized const fields.
> 
> What Java's 'final' does share with C++ const fields is that the compiler will diagnose attempts to modify the field after it is set. Java did it right, though, as Java doesn't allow casting away of constness, or non-const references to the same field modifying it out from under you. 'final' fields in Java are solid enough that the compiler can optimize based on it, and they have meaning in multithreaded apps, which is not the case in C++.
> 
> I have no issue with const and final as a storage class, I believe they are valuable and useful, and const is implemented as a storage class in D (its use could probably be profitably extended to more contexts). I don't agree with its value as a type modifier, for oft stated reasons that I will summarize as being that in legal, standard conforming C++ code the value of the presumably 'const' data can change at any moment. Const things ought to be, dagnamit, constant.

I'm getting too confused with all this 'storage class' and 'type modifier' talk. Sorry but I'm not a C++ nor a Java coder, so these terms are a bit cloudy. This is what I can understand so far from these discussions ...

const "storage class":
 The data is defined at compile time and RAM is reserved for the
information. No part of the application is allowed to modify the data
during run time.

const "type modifer":
 The data is stored by one part of the application but is not allowed to be
modified by another part of the application.

I can see a really good use for what I've called 'type modifier'. Passing something by reference to a routine, but not allowing that routine to modify the data passed to it. Currently, the only obvious way to do that in D is to pass a copy of the data and throw it away once the routine has returned.

  void Bar(char[] x)
  {
     x[4] = 'b';
  }

  void Foo(char[] X)
  {
     X[0] = 'a';
     Bar(x);
  }

  . . .
  char[] Y = "derek";
  Foo(Y.dup);  // Ignore any changes that 'Foo' might make to Y.


But a nicer, more obvious, more explicit in declaring coding intentions, would be do something like ...

  void Foo(PRESERVE char[] X)
  {
     X[0] = 'a';  // Compiler would flag this as an error.
     Bar(x);  // Compiler might have to pass a copy of x.
  }

  . . .
  char[] Y = "derek";
  Foo(Y);

I don't know how to implement this efficiently, but that is not the issue. The issue is that as a coder/designer, I must have the data in the passed argument to by unchanged after calling the routine.

-- 
Derek
Melbourne, Australia
8/03/2005 9:59:25 AM

> const "storage class":
>  The data is defined at compile time and RAM is reserved for the
> information. No part of the application is allowed to modify the data
> during run time.
> 

From an embedded systems point of view, const data can also live in ROM (well, it should be able to) - many small systems do use this trick to save RAM usage.  ROM also physically prevents you from modifying the variable, as such you shouldn't try to do dirty tricks to modify a const variable.  I bring this up because I do embedded stuff for a living, and I don't see anything in D which precludes it from being used in small systems.

Brad

"Kris" <Kris_member@pathlink.com> wrote in message news:d0ilcf$hbt$1@digitaldaemon.com...
> In article <d0iiqi$emd$1@digitaldaemon.com>, Walter says...
> >What Java's 'final' does share with C++ const fields is that the compiler will diagnose attempts to modify the field after it is set. Java did it right, though, as Java doesn't allow casting away of constness, or
non-const
> >references to the same field modifying it out from under you. 'final'
fields
> >in Java are solid enough that the compiler can optimize based on it, and they have meaning in multithreaded apps, which is not the case in C++.
> >
> >I have no issue with const and final as a storage class, I believe they
are
> >valuable and useful, and const is implemented as a storage class in D
(its
> >use could probably be profitably extended to more contexts). I don't
agree
> >with its value as a type modifier, for oft stated reasons that I will summarize as being that in legal, standard conforming C++ code the value
of
> >the presumably 'const' data can change at any moment. Const things ought
to
> >be, dagnamit, constant.
>
>
> Very glad to hear you opinion on this. I, for one, agree 100%.

Good. To put it another way, anything labeled as 'const' could be burned into ROM without changing the meaning of the program. (This is also implies that const data must have initializers that can be evaluated at compile time.)

> If you could provide a D mechanism for making scalar and vector data
"appear" to
> be fully constant (as in the storage class) to third-parties (think return
> values), then we'd have the read-only enforcement so many of us are crying
out
> for. That could easily become a major advantage for D over other
languages.
>
> In addition, the utility of a true storage-constant attribute (one that is
also
> supported via call-by-reference ~ inout obviously does not work) then that
would
> open up additional avenues for D.

Fundamentally connected with this is the problem of aliased function parameters. Get it wrong, as C and C++ do, and you cannot build an optimizer that is competitive with FORTRAN optimizers.