I would appreciate if Walter or maybe someone who assisted to the D conference could enlight me.

Taking a step back from the syntax/expressiveness debate, I would like to understand better where do const/invariant reside in the grand scheme of things. Is the current const/invariant the end goal, or does it lead to something else?

Why is const/invariant necessary?

- Is it just a checklist feature? [I think it's more than that, but C++ users are accustomed to this, it might be an handicap not to have it]

- Is it mainly there because it's required to implement something else? [Say, immutable string]

- Or is it there because it is useful just by itself? In that case, why? What's the *primary* intent?
 - To protect programmers from making mistakes?
 - For documentation?
 - As a "contract" in functions interface?
 - To enable certain optimizations?

And mainly, how does it stand with respect to pure function and functional programming? Is it required from that or is it more of a complementary feature?

Lots of questions....

guslay wrote:

> I would appreciate if Walter or maybe someone who assisted to the D conference could enlight me.
> 
> Taking a step back from the syntax/expressiveness debate, I would like to understand better where do const/invariant reside in the grand scheme of things. Is the current const/invariant the end goal, or does it lead to something else?
> 
> Why is const/invariant necessary?

I don't think I match your criteria for someone you want to hear from, but I'll try anyway ;)

I view const as part of an API specification.  Essentially a contract promising to not modify the data that is passed into a function (or held by a class, etc...).

Conceptually, this is useful (like in, out, ref parameters in functions) because it helps understand the intended functionality and gives a mechanism for the compiler to catch accidental violations of the intent.

Unfortunately, const (AKA readonly) does not do anything for the compiler besides giving it extra work to check code.  There's no guarantee that data won't be changed when calling functions or through actions of another thread.  Because of this, the compiler can not optimize code under the assumption that the data never changes.  As I understand it, this is the purpose of invariant.  I've also heard (but never seen justification/explanation) that invariant helps with functional programming.

I share a lot of your questions, and I hope someone who knows more than me can jump in and explain this stuff better.

Jason House wrote:
> I've also heard (but never seen
> justification/explanation) that invariant helps with functional
> programming.

I think it only helps in the sense that it makes automatic parallelization of functional-style programs possible.  If I foreach over some data structure and all the inputs are invariant, then the compiler is free to do that in any order or in parallel because it knows that executing a function on one element cannot possibly change the value of another element by any means.  With a C++ readonly style const you only know that you're not changing it, but there are a dozen ways that it could be changed out from under you in sneaky and unexpected, but perfectly legal, ways.

That said, I'm not sure what that's going to look like in D.  It seems like making use of invariant for functional programming in D will require a totally different programming style where you make everything invariant all the time.  It doesn't seem like you'll be able to just "toss in" a little FP to an existing project without a lot of redesign.

--bb

Bill Baxter Wrote:
> Jason House wrote:
> > I've also heard (but never seen
> > justification/explanation) that invariant helps with functional
> > programming.
> 
> I think it only helps in the sense that it makes automatic parallelization of functional-style programs possible.  If I foreach over some data structure and all the inputs are invariant, then the compiler is free to do that in any order or in parallel because it knows that executing a function on one element cannot possibly change the value of another element by any means.
[snip]

Invariant allows for alot of assumptions to be made about something; but it's because we assume merrily that it's okay for the program to crash if something changes out from under us even if the program is paused.

So we can:
- fearlessly run parallel functions over the same data
- cache something and expect it to be correct indefinitely
- trust our libraries, and 3rd parties not to mangle our stuff
- catch accidental writes to something we wanted read-only
- make guarantees to clients and employers (our code *cannot* change your x)
- be aware the opposite is probably true for non-invariants

In all honesty though, we must know it's a bluff.  The code *can* change out from under you.  It just won't by your own hand.

Regards,
Dan

Dan wrote:
> Bill Baxter Wrote:
>> Jason House wrote:
>>> I've also heard (but never seen
>>> justification/explanation) that invariant helps with functional
>>> programming.
>> I think it only helps in the sense that it makes automatic parallelization of functional-style programs possible.  If I foreach over some data structure and all the inputs are invariant, then the compiler is free to do that in any order or in parallel because it knows that executing a function on one element cannot possibly change the value of another element by any means.
> [snip]
> 
> Invariant allows for alot of assumptions to be made about something; but it's because we assume merrily that it's okay for the program to crash if something changes out from under us even if the program is paused.
> 
> So we can:
> - fearlessly run parallel functions over the same data
> - cache something and expect it to be correct indefinitely
> - trust our libraries, and 3rd parties not to mangle our stuff
> - catch accidental writes to something we wanted read-only
> - make guarantees to clients and employers (our code *cannot* change your x)
> - be aware the opposite is probably true for non-invariants
> 
> In all honesty though, we must know it's a bluff.  The code *can* change out from under you.  It just won't by your own hand.

So you're saying the likely usage patterns will involve giving the compiler "hints" in the form of casts to invariant on data that actually isn't?

--bb

guslay wrote:
> I would appreciate if Walter or maybe someone who assisted to the D conference could enlight me.

This is clearly a frequently asked question, so I added it to the FAQ:

http://www.digitalmars.com/d/faq.html#const

Bill Baxter wrote:
> Dan wrote:
>> Bill Baxter Wrote:
>>> Jason House wrote:
>>>> I've also heard (but never seen
>>>> justification/explanation) that invariant helps with functional
>>>> programming.
>>> I think it only helps in the sense that it makes automatic parallelization of functional-style programs possible.  If I foreach over some data structure and all the inputs are invariant, then the compiler is free to do that in any order or in parallel because it knows that executing a function on one element cannot possibly change the value of another element by any means.
>> [snip]
>>
>> Invariant allows for alot of assumptions to be made about something; but it's because we assume merrily that it's okay for the program to crash if something changes out from under us even if the program is paused.
>>
>> So we can:
>> - fearlessly run parallel functions over the same data
>> - cache something and expect it to be correct indefinitely
>> - trust our libraries, and 3rd parties not to mangle our stuff
>> - catch accidental writes to something we wanted read-only
>> - make guarantees to clients and employers (our code *cannot* change your x)
>> - be aware the opposite is probably true for non-invariants
>>
>> In all honesty though, we must know it's a bluff.  The code *can* change out from under you.  It just won't by your own hand.
> 
> So you're saying the likely usage patterns will involve giving the compiler "hints" in the form of casts to invariant on data that actually isn't?
> 
> --bb

I think he's trying to say that it's possible to cast away invariant.

Walter Bright wrote:
> guslay wrote:
>> I would appreciate if Walter or maybe someone who assisted to the D conference could enlight me.
> 
> This is clearly a frequently asked question, so I added it to the FAQ:
> 
> http://www.digitalmars.com/d/faq.html#const

Some of those FAQs need updating:
* Why doesn't D have an interface to C++ as well as C?
* Why cannot D code directly call existing C++ code?


Both should mention D2.0's C++ interfacing capabilities. (with link to here http://www.digitalmars.com/d/cpp_interface.html)

Walter Bright wrote:
> guslay wrote:
>> I would appreciate if Walter or maybe someone who assisted to the D conference could enlight me.
> 
> This is clearly a frequently asked question, so I added it to the FAQ:
> 
> http://www.digitalmars.com/d/faq.html#const

Small thing: "of little import" should probably read "of little importance"?

L.

Lionello Lunesu wrote:
> Walter Bright wrote:
>> guslay wrote:
>>> I would appreciate if Walter or maybe someone who assisted to the D conference could enlight me.
>>
>> This is clearly a frequently asked question, so I added it to the FAQ:
>>
>> http://www.digitalmars.com/d/faq.html#const
> 
> Small thing: "of little import" should probably read "of little importance"?

It's valid English.  The meaning is the same.

--bb