D, high-level, low-level, parameters

[Regan Heath]

On Tue, 21 Feb 2006 13:37:00 +0000 (UTC), Tom <Tom_member at pathlink.com>  
wrote:
> In article <ops5bhwscg23k2f5 at nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Mon, 20 Feb 2006 13:37:32 -0800, nick <nick.atamas at gmail.com> wrote:
>>> After reading the relevant discussion threads, I thought I would
>>> summarize my observations and normative thoughts.
>>>
>>> I. INTRO
>>> --------
>>> It seems to me that the discussions in the "unsafe" thread and the "In,
>>> inout, out, and damn lies...." are really touching on a larger issue.
>>>
>>> D aims to be a high-level language and a low-level systems language at
>>> the same time(*see footnote).  This seems to cause problems because the
>>> two approaches are inherently contradictory. Specifically, low-level
>>> constructs aim to hide nothing while high-level constructs aim to hide
>>> the bare metal.
>>> The implications are most vivid in how parameters are handled.  
>>> (Function
>>> declarations are interfaces, so this is to be expected.)
>>>
>>> With respect to parameter passing, I do not see any reason why a
>>> language couldn't do the following:
>>>
>>>
>>> II. HIGH-LEVEL
>>> --------------
>>> Everything is passed by reference.
>>> All the information the compiler needs can be conveyed by in/out/inout
>>> (we could also use read/write/readwrite).
>>>
>>> note: I treat arrays as objects and pointers as primitives.
>>>
>>> 1) For objects:
>>> 	in - read only; applies to ref and data
>>> 	out - can write data/ref; can read reference
>>> 	inout - can read and write; applies to ref and data
>>>
>>> note: One might replace 'can' with 'shall' but that's another  
>>> discussion.
>>>
>>> 2) For primitive types
>>> 	in - read only (passed by value as an optimization)
>>> 	out - passed by invisible reference; can write data
>>> 	inout - passed by invisible reference; can read/write data
>>>
>>>
>>> III. LOW-LEVEL
>>> --------------
>>> If someone is coding at the low-level, they presumably understand the
>>> high-level constructs but are also free to use pointers as they please
>>> to achieve any effect necessary.
>>>
>>>
>>> IV. DISCUSSION
>>> --------------
>>> My question is: "Why not use the above semantics? Is there something
>>> wrong with them?"
>>
>> No. The problem doesn't lie in the semantics but rather in how to  
>> enforce
>> "readonly". Walter has said that he does not like C++ const. I believe  
>> one
>> of the reason is because it does not guarantee protection, that the
>> protection can be circumvented via aliasing, making it a somewhat  
>> 'hollow'
>> promise, one which you therefore cannot rely on to be true at any stage.
>
> Can you throw an example of this stuff? Why is const bad? So by saying  
> it can be
> circumvented is enough to not implement something similar? With inline  
> asm any
> high level construct can be circumvented (i guess). That doesn't stop us  
> to use
> them.
>
> I really believe it's a good feature (as it'd be 'in' if it were so  
> strong as
> const). As a programmer many times I've seen "bad-coded" C++ functions  
> (that
> missed up to make const some of the input parameters) and made me and  
> others to
> waste LOT of time finding a bug.

There has been a *whole lot* of discussion in the past, let me point you  
to some threads on the subject:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15924
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18932
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24340
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24798
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25659
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25992
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26126
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26216
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26247
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26364
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26690
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26742

Some are directly on topic talking about const or readonly specifically,  
others are primarily about something else but at the root are a discussion  
on preventing write access to read only data.

Regan