September 10, 2007
Jari-Matti Mäkelä wrote:
> Bill Baxter wrote:
>> Nathan Reed wrote:
>>> Carlos Santander wrote:
>>>> Walter Bright escribió:
>>>>> o  So, we still need a method to declare a constant that will not consume memory. We'll co-opt the future macro syntax for that:
>>>>>     macro x = 3;
>>>>>     macro s = "hello";
>>>> Am I the only one who doesn't like this syntax? I guess it kinda makes sense, but I just don't like how it looks.
>>> Seems to me like this unnecessarily departs from the macro syntax introduced at the conference:
>>> macro foo(e) { e = 3; }
>>> (On the other hand, in one of them the macro is for an expression while in the other one it's a sequence of declarations/statements.  So maybe it is reasonable to have the different syntax.)
>> It's not far off from things used in some functional programming
>> languages, so it doesn't look to bad to me.  The word 'macro' typically
>> implies a direct, maybe even textual, substitution.  It's also a lot
>> like #define, just with an '=' there which I think is an improvement
>> over #define.  '=' for the no-arg macros, '{ }' for the arg-ful macros.
>>   Seems ok to me.
> And let's take another step forward (might scare off some old C farts,
> though, but I like it):
> T sum(T)(T a, T b) = a + b;
> For consistency's sake! :D

How about so?
T sum(T)(T a, T b) a + b;

This contains two things that I've feature requested before: implicit
return of the last expression in a function, and omitting { } for
one-statement functions.
My point being, it's somewhat closer to our current D than your
approach, in that it only requires two backwards-compatible extensions
instead of a whole new syntax :)

September 10, 2007
Russell Lewis wrote:
> Walter Bright wrote:
>  > (snip)
>> o  static const/invariant means the initializer is evaluated at compile time. non-static const/invariant means it is evaluated at run time.
> I'd like to suggest that we use some keyword other than "static."  Yeah, I know that "static" can imply "static analysis" (compile time), but the static modifier on a variable has a well-known meaning from C: it's not exported.  I think that that was a poor design choice in C, but now we're stuck with millions of programmers who expect it.

No one cares (or at least, should care) what that means in C. That's ancient history. More important is the other meaning that 'static' in *D itself*: the meaning of "non-instance / unique" which is really unrelated to "compile-time".

Bruno Medeiros - MSc in CS/E student
September 10, 2007
Janice Caron Wrote:

> On 9/10/07, Alexander Panek <> wrote:
> > What exactly is the is the difference between head and tail const?
> Suppose you have a pointer to pointer to pointer to pointer to pointer to int.
> (The length of this chain is irrelevant. I just threw lots in for the
> hell of it).
> Head const would be
> const pointer to pointer to pointer to pointer to pointer to int.
> Tail const would be
> pointer to const pointer to const pointer to const pointer to const
> pointer to const int.
This highlights another source of confusion for me.  I assumed tail const would be

pointer to pointer to pointer .... to const int.

What you have described I would call "rest const" using naive intuition.

> Total const would be
> const pointer to const pointer to const pointer to const pointer to
> const pointer to const int.
> i.e. head const and tail const both at the same time.

September 11, 2007
Sean Kelly Wrote:

> Walter Bright wrote:
> > Bruce Adams wrote:
> >>>> o  So, we still need a method to declare a constant that will not
> >>>>  consume memory. We'll co-opt the future macro syntax for that:
> >>>>
> >>>> macro x = 3; macro s = "hello";
> >> I'm not clear why this is even needed. Surely "static const" implies some level of don't consume any memory by virtue of meaning "available at compile time". If you need more than that, rather than trusting the compiler then I second "inline" rather than macro, but honestly I can't think of an example where this will give you a worthwhile performance gain (unlike an inline function).
> > 
> > windows.h in all its terrifying glory has 10,000 macro declarations. If each one occupied 4 bytes of static data, there's 40K of bloat in every exe.
> That sounds about right.  When we converted const values to enum values in the Tango Win32 headers, app size dropped by roughly 46k.  But there were issues with some of those enum values having the wrong type (-1 set to int instead of uint), which led to a few strange bugs.
> Sean

I seek enlightenmnet for at least two problems with that explanation.

windows.h is a C binding not a D binding.
I'm not clear how one translates to the other yet as I've avoided bi-lingual stuff so far. Presumably the D binding is created using htod.

I thought D followed the you only pay for what you use philosophy.
So if I import my windows.d module I will only pay the cost of the
variables I actually use. My friendly neighbourhoold compiler, being clever, mightl also make an effort to minimise the cost of those too.

While we're on the subject of windows. 40K means nothing. In an embedded system yes. Windows is bloated to the point where 40K in a user application means de nada. (I shudder at the 4Gb games that follow in its wake too). I have know idea where the windows mobile / CE / pocket PC api falls here.


September 11, 2007
Bruno Medeiros wrote:
> As Regan asked before, and how would that work for classes? This is a most fundamental issue that has not been mentioned. Without a way to declare tail const/invariant, this design, no matter how simpler or more understandable, is fundamentally *broken*.

What, exactly, is the use case that needs a solution?
September 11, 2007
Walter Bright Wrote:

> Russell Lewis wrote:
> > Walter Bright wrote:
> >> What we are trying to achieve:
> >>
> >> a) utility for functional programming
> >> b) better modularity by self-documenting interfaces better
> >> c) be able to treat reference types as if they were value types (i.e.
> >> strings should behave to the user like value types, even though they
> >> are references)
> > 
> > Is there a way to express (for a pointer passed as a function parameter) "the callee is allowed to modify this object through the pointer, but the caller ensures that no other code will be modifying it at the same time"?   Sort of a "you have exclusive write access" modifier?  Is that a common enough case to even support?
> That's sort of what the often proposed 'unique' type qualifier does. The problem is, there's just no reasonable way to implement it in a *checkable* manner. And if it ain't checkable, it's about as useful as painting a black stripe across your lap when driving instead of wearing a seatbelt.

I see a least two ways of interpreting it at run-time.
Acquire a lock before entering the function (or at least the parts where the value is modified) or in an STM atomic transaction roll-back and try again if the value is modified.
Being run-time only I suspect a function or template and lazy evaluation might suffice.

At compile time you could use it as a hint for 'linting' race conditions out of your code. That is a useful instrumentation to have.
(cyclist wearing a flourescent band as opposed to a black stripe)

These are just suggestions I wouldn't advocate anything without more thought. As I said on the next branch over this is off topic for a discussion about const.



September 11, 2007
Regan Heath wrote:
> In general is this correct for a class reference:
> class Baz { int a; }
> const Baz b;  //neither b nor b.a can be changed

September 11, 2007
Jb wrote:
> Am I the only one who though it odd that the current documentation spends twice as much time talking about C++ than it does about D?

Half of D programmers come from C++, and the easiest way to learn something new is to relate it to something already known.
September 11, 2007
There is no way to find an optimal const solution without trying every possible const solution.

(IIRC what "NP Complete" is, might be "NP really stinking hard" I'm thinking of <G>)

September 11, 2007
Walter Bright wrote:
> Const, final, invariant, head const, tail const, it's grown into a monster. It tries to cover all the bases, but in doing so is simply not understandable.

I was going to say that, that D's const sucks, many months ago, but didn't because I was afraid being regarded as a troll.

Its not that I like const-less languages like Java (in fact, I hate them), but I think that C++'s const, with all its problems, was the right answer (for that time). It fixes the problem without putting much burden onto the programmer.

D's const puts way too much burden onto the programmer, and gives very little back. Too many different combinations of const, final, invariant, pointers and references (and the fact that in D you don't immediately know if a type "T" is a reference of a value, specially while writing templates, adds to this confusion) with confusing semantics when combined (with a few special cases and lack of orthogonality).

When the new const was being designed, I told in this list: "Don't try to fix what ain't broken". What I meant was: Don't try to do a new const just because you want a better const than C++s. Many people dislike C++s const, but are unable to point exactly why it is wrong. Most people doesn't even understand C++'s const, and try to get more from it than it was actually intended to provide (that is the whole point behind the new D's invariant).

Sometimes people give use-cases to exemplify (STL's need for a
difference between iterator<> and const_iterator<> is the first thing
that comes to my mind), but then you ask what a language could provide
to fix this, they don't know. This is where you should aim first you laser.

When I first saw D, I was amazed with the possibilities. Now I'm somewhat scared. Perhaps one of the things that are scaring me is just like you said: there is a (at least one) monster in the language.

Just my two cents... I have no interest in trolling anyone.
1 2 3 4 5 6 7 8 9 10 11 12