May 14, 2012
On Sunday, May 13, 2012 20:40:51 Walter Bright wrote:
> On 5/13/2012 8:19 PM, Jonathan M Davis wrote:
> > This is in definite contrast to C++ where you
> > _can_ avoid const completely if you want to.
> 
> That's because C++ const is just documentation for the programmer, and offers no reliable enforcement.
May 14, 2012
On Sunday, May 13, 2012 20:40:51 Walter Bright wrote:
> On 5/13/2012 8:19 PM, Jonathan M Davis wrote:
> > This is in definite contrast to C++ where you
> > _can_ avoid const completely if you want to.
> 
> That's because C++ const is just documentation for the programmer, and offers no reliable enforcement.

True, but the point is that the pros and cons of D's const and C++'s const are different, and wihle D's const is more powerful, that power does come with a cost, and it's difficult to avoid D's const completely, whereas C++'s const is quite easy to avoid.

- Jonathan M Davis
May 14, 2012
On Monday, 14 May 2012 at 04:18:32 UTC, Jonathan M Davis wrote:
> Oh, it's definitely useful for optimizations. It just doesn't work with a couple of idioms that some programmers like to use in order to optimize their code.

 Perhaps bad practices and styles hard-coded in their psyche due to limitations and issues with the other language?

 If there's something that gets in the way with what's made sense to you; You'll either try to figure it out (manual and forums) or backtrack to what you do understand and perhaps get even more stuck than before.


 I was in the military for a time; In Basic Training they told us 'forget everything (you think) you know about firing your rifle'. They taught you from scratch how they wanted you to do it. In programming there's no real 'from scratch' after you're used to it a certain set of ways, and relearning something that already makes sense to you makes you unconsciously skip things you otherwise wouldn't.


May 14, 2012
On Mon, May 14, 2012 at 06:55:02AM +0200, Era Scarecrow wrote: [...]
>  I was in the military for a time; In Basic Training they told us
> 'forget everything (you think) you know about firing your rifle'.
> They taught you from scratch how they wanted you to do it. In
> programming there's no real 'from scratch' after you're used to it a
> certain set of ways, and relearning something that already makes
> sense to you makes you unconsciously skip things you otherwise
> wouldn't.
[...]

Part of the pitfall of D being part of the C-derived language family is that people (mainly the C++/Java/C# crowd) unconsciously carry over their assumptions of how things work from the other languages, and they try to do things the same way in D and keep running into barriers, because D just isn't designed to work that way.

That's part of the reason I didn't really get comfortable with D programming until I bought TDPL -- I needed to learn D "from scratch", as it were, to think about it from a fresh perspective instead of bringing along my years of C/C++ baggage. For that, looking at a bunch of online reference docs didn't help: you're just learning the "vocabulary", as it were, and not really "thinking in the language". As any foreign language learner knows, you will never speak the language well if you just keep translating from your native language; you have to learn to "think in that language". I needed to read through TDPL like a newbie in order to learn to write D the way it's supposed to be written.

Once I started doing that, many things began to make a lot more sense.


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz
May 14, 2012
On 14-05-2012 06:18, Jonathan M Davis wrote:
> On Monday, May 14, 2012 05:47:54 Alex Rønne Petersen wrote:
>> It's kinda funny that something which on dlang.org's FAQ is described as
>> a compiler optimization hint (http://dlang.org/const-faq.html#const)
>> isn't useful at all for this purpose...
>
> Oh, it's definitely useful for optimizations. It just doesn't work with a
> couple of idioms that some programmers like to use in order to optimize their
> code.
>
> - Jonathan M Davis

I have yet to see any compiler make sensible use of the information provided by both C++'s const and D's const.

const in particular is completely useless to an optimizer because it does not give it any information that it can use for anything. The kind of information that an optimization pass, in general, wants to see is whether something is guaranteed to *never* change. const does not provide this information. const simply guarantees that the code working on the const data cannot alter it (but at the same time allows *other* code to alter it), which, as said, is useless to the optimizer.

immutable is a different story. immutable actually opens the door to many optimization opportunities exactly because the optimizer knows that the data will not be altered, ever. This allows it to (almost) arbitrarily reorder code, fold many computations at compile time, do conditional constant propagation, dead code elimination, ...

This seems reasonable. But now consider that the majority of functions *are written for const, not immutable*. Thereby, you're throwing away the immutable guarantee, which is what the *compiler* (not the *programmer*) cares about. immutable is an excellent idea in theory, but in practice, it doesn't help the compiler because you'd have to either

a) templatize all functions operating on const/immutable data so the compiler can retain the immutable guarantee when the input is such, or
b) explicitly duplicate code for the const and the immutable case.

Both approaches clearly suck. Templates don't play nice with polymorphism, and code duplication is...well...duplication. So, most of druntime and phobos is written for const because const is the bridge between the mutable and immutable world, and writing code against that rather than explicitly against mutable/immutable data is just simpler. But this completely ruins any opportunity the compiler has to optimize!

(An interesting fact is that even the compiler engineers working on compilers for strictly pure functional languages have yet to take full advantage of the potential that a pure, immutable world offers. If *they* haven't done it yet, I don't think we're going to do it for a long time to come.)

Now, you might argue that the compiler could simply say "okay, this data is const, which means it cannot be changed in this particular piece of code and thus nowhere else, since it is not explicitly shared, and therefore not touched by any other threads". This would be great if shared wasn't a complete design fallacy. Unfortunately, in most real world code, shared just doesn't cut it, and data is often shared between threads without using the shared qualifier (__gshared is one example).

shared is another can of worms entirely. I can list a few initial reasons why it's unrealistic and impractical:

1) It is extremely x86-biased; implementing it on other architectures is going to be...interesting (read: on many architectures, impossible at ISA level).
2) There is no bridge between shared and unshared like there is for mutable and immutable. This means that all code operating on shared data has to be templatized (no, casts will not suffice; the compiler can't insert memory barriers then) or code has to be explicitly duplicated for the shared and unshared case. Funnily, the exact same issue mentioned above for const and immutable!
3) It only provides documentation value. The low-level atomicity that it is supposed to provide (but doesn't yet...) is of extremely questionable value. In my experience, I never actually access shared data from multiple threads simultaneously, but rather, transfer the data from one thread to another and use it exclusively in the other thread (i.e. handing over the ownership). In such scenarios, shared just adds overhead (memory barriers are Bad (TM) for performance).

/rant

-- 
- Alex
May 14, 2012
On Monday, 14 May 2012 at 03:19:57 UTC, Jonathan M Davis wrote:
> I suspect that the folks who are looking for absolutely every CPU cycle and want caching and lazy-loading in their types

It's not a CPU cycle issue.

Caching/lazy-loading can make the difference between a window that freezes, and a window that doesn't.
May 14, 2012
On Monday, 14 May 2012 at 04:10:30 UTC, Chris Cain wrote:
> Let me ask you something: Could you try to name 2 or 3 good things about const/immutable without looking it up? If not, you've really not given enough effort to learning about the benefits of it.


(1) Compiler helps you write correct multithreaded code
(2) You help compiler perform optimizations based on contracts
(3) I don't think there exists a #3 that's very different from #1 and #2




I'm not saying const is bad (at least, that's not what I'm saying *here*).

What I'm saying is that it's being forced upon the user, and it's becoming unavoidable. Which means people who don't like it won't use D.

Kind of like the GC.
May 14, 2012
On 5/13/2012 11:09 PM, Mehrdad wrote:
> On Monday, 14 May 2012 at 04:10:30 UTC, Chris Cain wrote:
>> Let me ask you something: Could you try to name 2 or 3 good things about
>> const/immutable without looking it up? If not, you've really not given enough
>> effort to learning about the benefits of it.
>
>
> (1) Compiler helps you write correct multithreaded code
> (2) You help compiler perform optimizations based on contracts
> (3) I don't think there exists a #3 that's very different from #1 and #2


#3 Improves self-documentation of code - it's more understandable and less susceptible to breakage during maintenance.

#4 Improves encapsulation

#5 Makes function purity possible
May 14, 2012
On 14-05-2012 08:26, Walter Bright wrote:
> On 5/13/2012 11:09 PM, Mehrdad wrote:
>> On Monday, 14 May 2012 at 04:10:30 UTC, Chris Cain wrote:
>>> Let me ask you something: Could you try to name 2 or 3 good things about
>>> const/immutable without looking it up? If not, you've really not
>>> given enough
>>> effort to learning about the benefits of it.
>>
>>
>> (1) Compiler helps you write correct multithreaded code
>> (2) You help compiler perform optimizations based on contracts
>> (3) I don't think there exists a #3 that's very different from #1 and #2
>
>
> #3 Improves self-documentation of code - it's more understandable and
> less susceptible to breakage during maintenance.
>
> #4 Improves encapsulation

I'm not sure I would agree on this one. const/immutable arguably leak implementation details more than they encapsulate them.

>
> #5 Makes function purity possible

-- 
- Alex
May 14, 2012
On Sunday, 13 May 2012 at 17:02:46 UTC, Stewart Gordon wrote:
> On 13/05/2012 17:41, Alex Rønne Petersen wrote:
> <snip>
>> I agree with everything but toString(). I'm afraid that forcing toString() to be const
>> will have harm flexibility severely. Can't we do better, somehow?
>
> How exactly?
>
> If you're talking about memoization, it ought to be possible to make use of std.functional.memoize to implement it.
>
> Otherwise, using toString to change the state of an object is bending semantics.  If you want a method to generate a string representation of an object in a way that might do this, then create your own method to do it.
>
> Stewart.

How about logically constant opEquals, toString etc? Currently, this is perfectly possible by just *not using const*. Logical constancy goes beyond memoization.

For example, take this function:

http://jakobovrum.github.com/LuaD/luad.base.html#LuaObject.opEquals

It cannot be const because Lua instances are state machines. The function pushes the this-object to the Lua stack, then it pushes the object to compare to, then it uses a Lua API comparison function which pops the two objects and pushes the comparison result. The result is then popped off the stack and returned as a boolean.

The function is logically constant, hence it does not use D's const, which should be a completely valid choice to make.