nick wrote:
> Pointer problems are notoriously difficult to track. Pointers are a
> feature that is not necessary in 90% of production code. Hey, Joel
> called them DANGEROUS. (I'm going to use that one a lot now.)
> 
> My example demonstrates a potential error that, if occurs in a library
> that you don't have source for, will cause you hours of grief. My
> example was carefully constructed. In it an object was passed in using
> the /in/ keyword. That should guarantee that my copy of the object
> doesn't change. If you are saying it is OK for it to change, then you
> are basically saying that the /in/ keyword is useless (well, not really
> useless but almost). I don't think that's cool.

'in' just indicates call by value, and in the case of objects, only the reference is passed by value.  No guarantee of immutability is being provided.  Doesn't Ada use the same in/out/inout syntax?


Sean

"nick" <nick_member@pathlink.com> wrote in message news:dsqr3t$2seg$1@digitaldaemon.com...
> I think that if we changed the semantics of /in/ or provided some
> equivalent of
> a 'const type*', that would help.

I agree, but in investigating this it turned out to be quite a quagmire, so I abandoned it for now.

Matthew wrote:
> "nick" <nick.atamas@gmail.com> wrote in message news:dsp5ak$s35$1@digitaldaemon.com...
> 
>> When will people finally realize that stupid an unexperienced aren't the
>> same thing. . . . Most
>> programmers are amateurs; you're not going to change that. Furthermore,
>> humans are prone to error.
> 
> True. But you can't hobble "production" programmers to cater for hobbyists. That's just not a go-er. Isn't it better to do what D has done, and allow for the low down and dirty while fostering and promoting a generally more suitable higher-level of abstraction?
> 
> Type-safety, const-correctness, and all such things are very good. Basically, whatever you can get the compiler to do for you is a good thing. Just as long as you can circumvent it when you need to. In both these areas, I think D has some way to go, but it's better than most.

Agreed.  And frankly, I would be fine with using an 'unsafe' attribute so long as doing so didn't prevent me from being as evil as the situation demanded.  However, I reserve the right to complain if it's annoying to use ;-)


Sean

On Tue, 14 Feb 2006 07:44:45 +1100, nick <nick_member@pathlink.com> wrote:

> In article <dspn17$1lbq$1@digitaldaemon.com>, Walter Bright says...
>>
>>
>> 3) Finding attractive alternatives to common uses of unsafe practices - out
>> and inout parameters are a good example here.
> I like the syntax of in, out and inout - it's very explicit. However, when it
> comes to objects, I am not sure sure the semantics are the best at the moment.
>
> For example, given this code:
> class A{ public int q;}
> void surprise( in A a ){a.q = 5;}
>
> a call to surprise(a) will change the value of 'a'. Is there no way to guarantee
> that the value of 'a' doesn't change in a function?


Sorry to interrupt, but its important to get some terms strightened out here. The 'in' qualifier does in fact protect the value of the parameter passed. In your example, it does protect the value of 'a'; that is it does not permit any changes to the object reference to be returned to the caller. However, the 'in' qualifier does *not* protect the object to which 'a' refers. In short, it protects the reference but not the referred.

For example, when passed to your example, 'a' is the address of a class instance - it is not the instance itself, just its RAM address. Any changes you make to that address is not returned to the caller. The only way (currently) to protect the object itself, is to take a copy of it and work with the copy. This applies to class instances and to arrays.


> I think that if we changed the semantics of /in/ or provided some equivalent of a 'const type*', that would help.

I'd only go as way as saying that I'd like to see some form of syntax to alert the compiler and maintainer of the intention of the coder and thus warn us of overt or explicit attempts to change data inside such a 'protected' object or array.
This should still allow other methods to modify objects but not make it easy to do.

-- 
Derek Parnell
Melbourne, Australia

Sean Kelly wrote:
> nick wrote:
>> Pointer problems are notoriously difficult to track. Pointers are a feature that is not necessary in 90% of production code. Hey, Joel called them DANGEROUS. (I'm going to use that one a lot now.)
>>
>> My example demonstrates a potential error that, if occurs in a library that you don't have source for, will cause you hours of grief. My example was carefully constructed. In it an object was passed in using the /in/ keyword. That should guarantee that my copy of the object doesn't change. If you are saying it is OK for it to change, then you are basically saying that the /in/ keyword is useless (well, not really useless but almost). I don't think that's cool.
> 
> 'in' just indicates call by value, and in the case of objects, only the reference is passed by value.  No guarantee of immutability is being provided.  Doesn't Ada use the same in/out/inout syntax?
> 
> 
> Sean

Yeah, I think we're on the same page as far as the facts. I am just not so happy about the lack of const. Although, as Walter pointer out, there is no good way that he found.

"nick" <nick.atamas@gmail.com> wrote in message news:dsrhuq$i9p$1@digitaldaemon.com...
> Sean Kelly wrote:
>> nick wrote:
>>> Pointer problems are notoriously difficult to track. Pointers are a feature that is not necessary in 90% of production code. Hey, Joel called them DANGEROUS. (I'm going to use that one a lot now.)
>>>
>>> My example demonstrates a potential error that, if occurs in a library that you don't have source for, will cause you hours of grief. My example was carefully constructed. In it an object was passed in using the /in/ keyword. That should guarantee that my copy of the object doesn't change. If you are saying it is OK for it to change, then you are basically saying that the /in/ keyword is useless (well, not really useless but almost). I don't think that's cool.
>>
>> 'in' just indicates call by value, and in the case of objects, only the reference is passed by value.  No guarantee of immutability is being provided.  Doesn't Ada use the same in/out/inout syntax?
>>
>>
>> Sean
>
> Yeah, I think we're on the same page as far as the facts. I am just not so happy about the lack of const. Although, as Walter pointer out, there is no good way that he found.

Perhaps if people considered readonly, rather than const, it'd seem more workable.

readonly would mean only the code seeing that decorator is prevented by the compiler from altering it. In other words, this impacts only on logical constness within the current context.

readonly would have nothing whatsoever to do with physical constness.

IIRC most, though not all, of Walter's objections have pertained to the physical subversion of logical constness, and how that may impact code generation and other compilery things I don't understand.

"Matthew" <nowhere@noaddress.co.us> wrote in message news:dsri7o$j2i$1@digitaldaemon.com...
>
> "nick" <nick.atamas@gmail.com> wrote in message news:dsrhuq$i9p$1@digitaldaemon.com...
>> Sean Kelly wrote:
>>> nick wrote:
>>>> Pointer problems are notoriously difficult to track. Pointers are a feature that is not necessary in 90% of production code. Hey, Joel called them DANGEROUS. (I'm going to use that one a lot now.)
>>>>
>>>> My example demonstrates a potential error that, if occurs in a library that you don't have source for, will cause you hours of grief. My example was carefully constructed. In it an object was passed in using the /in/ keyword. That should guarantee that my copy of the object doesn't change. If you are saying it is OK for it to change, then you are basically saying that the /in/ keyword is useless (well, not really useless but almost). I don't think that's cool.
>>>
>>> 'in' just indicates call by value, and in the case of objects, only the reference is passed by value.  No guarantee of immutability is being provided.  Doesn't Ada use the same in/out/inout syntax?
>>>
>>>
>>> Sean
>>
>> Yeah, I think we're on the same page as far as the facts. I am just not so happy about the lack of const. Although, as Walter pointer out, there is no good way that he found.
>
> Perhaps if people considered readonly, rather than const, it'd seem more workable.
>
> readonly would mean only the code seeing that decorator is prevented by the compiler from altering it. In other words, this impacts only on logical constness within the current context.
>
> readonly would have nothing whatsoever to do with physical constness.
>
> IIRC most, though not all, of Walter's objections have pertained to the physical subversion of logical constness, and how that may impact code generation and other compilery things I don't understand.
>
>

I think that Walter is looking for something like this: http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2005.pdf

It is a Javari - Java with readonly.
I think that this paper of Matthew Tschantz  and Michael Ernst
is the most comprehensive study on the subject.

This is how it should be done in ideal world.

Andrew.

The ability to protect not a reference, but the memory a reference points to is a feature that (at least a few) people have been asking for for some time.  (Think: real constant arrays.)  Walter, this is something you've said is a 2.0 feature, yes?  Nick, this would satisfy your issue with a reference "in" parameter?

~John Demme

Walter Bright wrote:

> 
> "nick" <nick_member@pathlink.com> wrote in message news:dsqr3t$2seg$1@digitaldaemon.com...
>> I think that if we changed the semantics of /in/ or provided some
>> equivalent of
>> a 'const type*', that would help.
> 
> I agree, but in investigating this it turned out to be quite a quagmire, so I abandoned it for now.

"Matthew" <nowhere@noaddress.co.us> wrote in message news:dsri7o$j2i$1@digitaldaemon.com...
> IIRC most, though not all, of Walter's objections have pertained to the physical subversion of logical constness, and how that may impact code generation and other compilery things I don't understand.

It's not just that. It's that there are many different definitions of const, each with its own advantages and problems. C++ uses two of them (confusingly conflated).

1) is the reference const?
2) is what the reference refers to const?
3) does (2) apply recursively?
4) is it only const by that reference, i.e. can other references to the same
data concurrently modify it?
5) is it ROMable?
6) is it initialize-once?
7) is it an error to subvert const'ness, or is it legal? (Since D has
pointers, one can always find a way to subvert it, the question is is that
defined behavior.)
8) is there a place for 'mutable' members of const objects?
9) how does aliasing (multiple references to the same data) fit into all
this?
10) does C++ have it backwards - const should be the default, and non-const
should be explicit?
11) what happens when a const reference is supplied to a non-const
reference?
12) is there a way to do const that can take advantage of hardware support
for read-only?
13) how can const fit in with the notion of COW?
14) how does this fit in with the notion of an atomic function (a function
with no side effects)?
15) how to do this in an aesthetically pleasing way that has a
slap-ones-head-of-course-thats-the-way-to-do-it obviousness about it that
everyone missed before? <g>

I've asked a friend who's a languages expert about this, who views programming languages through the lense of academic rigor, and he unhelpfully suggested D do all variations <sigh>.

My views on the failings of C++ const are pretty well documented in these n.g.'s, so I shan't repeat them. Suffice to say whatever D gets won't look or behave like that, and D is better off with no const at all than the C++ const. (I might add, however, that D does have C++'s readonly notion of const, and that works well. Just not the type modifier version.)

"John Demme" <me@teqdruid.com> wrote in message news:dsrn2u$m91$2@digitaldaemon.com...
> The ability to protect not a reference, but the memory a reference points
> to
> is a feature that (at least a few) people have been asking for for some
> time.  (Think: real constant arrays.)  Walter, this is something you've
> said is a 2.0 feature, yes?

Yes.