September 12, 2007
> You obviously missed the discussion of the "pure" keyword, borrowed from Fortran-90 from the conference. This is a clear way of declaring that a function must not have any side-effects.


Cool!

But then, I don't understand Walter's objections to "logical constness".

Seems pretty simple to me. If a function is logically const but not truly const, then don't declare it pure.

Conversely, if it's not declared pure, then it can have logical constness.

Isn't that problem solved?
September 12, 2007
> All I can find on the net about COW programming is the COW programming language.  I'm sure this isn't what you meant :)  can you please explain this further?

I suspect he meant "copy on write", but forget to tell us. :-)
September 12, 2007
Steven Schveighoffer wrote:
> class X
> {
>   const int void f()
>   {
>     x += 5;
>     return x;
>   }
> }

"const int void f()" is clearly a bad declaration. Anyway, "const int f()" is a function returning a const int, not a const function returning an int, so you wouldn't be able to call it through a const reference.

 - Gregor Richards
September 12, 2007
> I suspect he meant "copy on write", but forget to tell us. :-)

Here's an example of copy-on-write:

MyString s = "cat";
MyString t = s; /* Only a reference is copied. Now s and t both
reference the same data */
writefln(t); /* prints "cat" */

/*drum roll*/
t[0] = 'b'; /* Only now is a copy made. Now t is unique, with s=="cat"
and t="bat" */
writefln(s); /* prints "cat" */
writefln(t); /* prints "bat" */

Of course, to implement this - to actually create a class that did this, you'd need MyString to have some internal state (and therefore, either non-transitive const, or logical const).
September 12, 2007
"Gregor Richards" wrote
> Steven Schveighoffer wrote:
>> class X
>> {
>>   const int void f()
>>   {
>>     x += 5;
>>     return x;
>>   }
>> }
>
> "const int void f()" is clearly a bad declaration. Anyway, "const int f()" is a function returning a const int, not a const function returning an int, so you wouldn't be able to call it through a const reference.
>
>  - Gregor Richards

Um... yeah, I meant to say f() is const.  Sorry my example code didn't compile for you :P

-Steve


September 12, 2007
> "const int void f()" is clearly a bad declaration. Anyway, "const int f()" is a function returning a const int, not a const function returning an int, so you wouldn't be able to call it through a const reference.

See thread "properties and const"

The D syntax for "member function which does not modify member variables" is sort of a bit unclear. In C++ I would have written "int void f() const", but that's not how it goes in D.
September 12, 2007
Walter Bright wrote:
> Sean Kelly wrote:
>>
>> I suspect this means that D apps won't look very much like C++ apps in terms of how const is used, and the overall utility for the average programmer may well be somewhat small.
> 
> Yes, it will be used differently. Whether it is overall better or not only experience will tell.

This was perhaps too strong a statement on my part.  Given the design of const, I'm beginning to suspect that while the syntax of D is fairly similar to C++, I think the structure of a D app five years from now may well look very little like that of a C++ app.  The recent D features all lend themselves to a more functional style of programming.  This is probably a good thing in terms of scaling towards the future, but it could be surprising for someone who thinks D is C merged with Java :-)


Sean
September 12, 2007
Steven Schveighoffer wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
>> 1) Make functional style programming possible, which will become extremely important as people will start using all those lovely cores.
> 
> How does making const transitive allow for functional programming?  From what I understand (and that's not much) about functional programming, it's programming without side effects.  Consider:

Although const is necessary for f.p., it is not sufficient for f.p., as your example illustrates.

> I think in order to allow functional programming, you need to introduce a new type of const, for example fconst.  If a function is declared fconst, it is not allowed to change any data that is not local to the function, or call a non-fconst function, or to read non-fconst data.  If a piece of data is declared fconst, it cannot be changed.

The thought is to declare a function as 'pure'.


>> 3) Be able to treat invariant references as value types. This, for example, makes manipulating strings as easy as manipulating ints.
> 
> I don't understand this, perhaps someone can explain it further.  An example of how this helps would be good.

Strings in, say, Perl or Basic "just work". Just like integers "just work" in C. Nobody ever gives a thought to them inadvertently changing value.

But strings in C, everybody worries about them changing value, and such is a major source of bugs.

>> 4) Makes COW programming checkable and enforceable. (COW programming is an important part of many styles of programming.) Without transitive const, COW is overly reliant on programmer discipline.
> 
> All I can find on the net about COW programming is the COW programming language.  I'm sure this isn't what you meant :)  can you please explain this further?

copy-on-write
September 12, 2007
Sean Kelly wrote:
> This was perhaps too strong a statement on my part.  Given the design of const, I'm beginning to suspect that while the syntax of D is fairly similar to C++, I think the structure of a D app five years from now may well look very little like that of a C++ app.  The recent D features all lend themselves to a more functional style of programming.  This is probably a good thing in terms of scaling towards the future, but it could be surprising for someone who thinks D is C merged with Java :-)

Interestingly, the look of C++ apps have changed *substantially* over time as new philosophies of how to use it have evolved.

One could note that I'm a bit stuck in the past, as my C++ code (the D front end) is definitely an old style of C++. It has very little in common with the modern style (see Boost for that).
September 12, 2007
Alex Burton wrote:
> While const is being reexamined....
> 
> I create an interface :
> 
> interface Server
> {
>     Data getData() const;
> };

Hello, world! I'm fairly new to the world of D, but a minor detail like that has never stopped me from butting in so far ;) I'm sorry if any of my points have been made before, but I don't really feel like trawling through all 50.000 posts (although I have made an effort to dig into the more recent ones)

First of all, I think specifying an interface method to be const is bad practice. The interface is assuming things about a possible implementation that is really not its business. As you describe, this will hinder your implementation.

I understand you're not able to specify your particular getData() implementation as const due to const's transitivity, but as far as I'm concerned them's the breaks. I'm a bit of a const purist, sorry.

What I would like to see regarding const and interfaces, is that the _implementation_ should be able to guarantee const-correctness even if the interface doesn't, much like covariant return types. The implementation should be free to guarantee more than its interface. That doesn't help you though...


Best regards,
Carsten Sørensen