View mode: basic / threaded / horizontal-split · Log in · Help
February 13, 2006
Re: unsafe
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
February 13, 2006
Re: unsafe
"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.
February 13, 2006
Re: unsafe
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
February 13, 2006
Re: unsafe
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
February 14, 2006
Re: unsafe
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.
February 14, 2006
Re: unsafe
"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.
February 14, 2006
Re: unsafe
"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.
February 14, 2006
Re: unsafe
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.
February 14, 2006
Re: unsafe
"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.)
February 14, 2006
Re: unsafe
"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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home