D, high-level, low-level, parameters

[Tom]

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.

Tom;