View mode: basic / threaded / horizontal-split · Log in · Help
September 12, 2007
Re: Transitive const sucks
> 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
Re: Transitive const sucks
> 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
Re: Transitive const sucks
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
Re: Transitive const sucks
> 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
Re: Transitive const sucks
"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
Re: Transitive const sucks
> "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
Re: Transitive const sucks
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
Re: Transitive const sucks
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
Re: Transitive const sucks
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
Re: Transitive const sucks
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home