On Thu, 14 Jul 2005 16:10:05 +0000 (UTC), Dave <Dave_member@pathlink.com> wrote:
> In article <db4umv$1spa$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opstvj1qwe23k2f5@nrage.netwin.co.nz...
>>> On Wed, 13 Jul 2005 16:08:08 -0700, Andrew Fedoniouk
>>> <news@terrainformatica.com> wrote:
>>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>>> news:opstvgxmlz23k2f5@nrage.netwin.co.nz...
>>>>> On Thu, 14 Jul 2005 09:56:02 +1200, Regan Heath <regan@netwin.co.nz>
>>>>> wrote:
>>>>>> On Wed, 13 Jul 2005 13:29:24 -0700, Andrew Fedoniouk
>>>>>> <news@terrainformatica.com> wrote:
>>>>>>> Such explicit 'in' needs 'mutable' designators for all methods
>>>>>>> allowing
>>>>>>> to change state of structure/class. This is the main concern with
>>>>>>> 'const' in C++
>>>>>>>
>>>>>>> Again 'in' is a direction of information flow. Please don't mix them
>>>>>>> with
>>>>>>> constantess.
>>>>>>> Through 'in' you can pass both mutable reference and immutable
>>>>>>> reference.
>>>>>>> 'in' just means that changes of reference value itself will not be
>>>>>>> visible
>>>>>>> for a caller - it is far from "this pointer is only for reading".
>>>>>>
>>>>>> There are several ways you might want to pass a parameter:
>>>>>>
>>>>>> 1. read only. the mechanism of passing copy/byref isn't important you
>>>>>> just want a variable you can only read from. the compiler could
>>>>>> essentially decide to pass this in any way it likes. if passed byref it
>>>>>> would have to enforce read only.
>>>>>>
>>>>>> 2. copy. you want a copy that you can modify inside the function for
>>>>>> the
>>>>>> duration of the function.
>>>>>>
>>>>>> 3. refrence. you want the actual variable so that you can modify it
>>>>>> inside the function.
>>>>>>
>>>>>> Right now D has 2 and 3 covered but not 1. The OP is suggesting
>>>>>> something that makes #1 possible, and changes #2 so it is only possible
>>>>>> if the programmer codes it explicitly. #3 remains the same.
>>>>>
>>>>> Sorry, by OP I meant "Dave".
>>>>>
>>>>> I realise in, out, and inout currently specify how to pass a variable,
>>>>> but, in they also allow the programmer to declare how they intend to use
>>>>> the variable. So while technically they do not declare constness or
>>>>> similar they imply it in cases.
>>>>>
>>>>> I can't really see a point in ever passing byval, we can instead pass
>>>>> byX
>>>>> (compilers choice) ...
>>>>
>>>> Are we in gambling business or what?
>>>
>>> No, because the point you're missing is that it doesn't matter at all how
>>> it passes it if you only read from it, does it? (ignoring efficiency for a
>>> sec, as that is how the compiler will choose to pass it)
>>
>> Oh, no, please... this horse is dead already...
>>
>> "1. ... if passed byref it would have to enforce read only."
>>
>> How the hell compiler will enforce it? This is the whole point.
>>
>
> Basically, what I (and I think Regan) have in mind is that the compiler would
> enforce 'in' params. the same way a C++ compiler would enforce "const [type]" or
> "const [type] &" params. for analogous types in C++. That way you would get 'C++
> const' functionality for params by default (implicit in params would act like
> Walter's 'explicit in' proposal too).
>
> The difference would be that in D, although it wouldn't be enforced "deeply" by
> the compiler (because as you've pointed out many times that isn't practical),
> implicit and explicit 'in' would carry a 'gentlemen's agreement' that these are
> immutable so that 'in' could have semantic value.
>
> I think that a pretty high majority of the "oops" cases would be caught by the
> "const [type] &" checks analogous to what a good C++ compiler does and then the
> programmer would have to change the param to out or inout or explicitly make a
> copy. For the other cases it would be undefined behaviour because the 'contract'
> is being broken.
>
> The reasons this makes sense to me are this:
>
> - It would cover most cases and therefore eliminate peppering function
> declarations with type/storage modifiers.
> - It wouldn't add anything to D syntax.
> - It would provide (and enforce) the same C++ const type functionality that it
> seems a lot of people in this discussion have been referring to.
> - It would seperate how a parameter is passed (byref or byval) from what type it
> is (struct, class, array, primitive, pointer) so a D programmer could stop
> thinking about that and the compiler could do what makes the most sense when
> passing vars. w/o the programmer having to tack '&' onto every param.
> - Since 'implicit in' parameters are probably and will stay a good majority, the
> compiler could take advantage of the contract to produce better code inside the
> function for expressions involving the 'in' params.
> - It would reinforce the idea that the 'direction' of a param. should coincide
> with whether or not it is modified inside a function. For example, when passing
> an instance of a class 'in', you can now (legally) directly modify primitive
> members of that class and those modifications live past the lifetime of that
> function call. However, passing an instance of a struct modifying the member
> won't in many cases, which just seems contradictory to me:
>
> class C { int i = 10; }
> struct S { int i = 10; }
>
> template foo(T) { void foo(in T o) { o.i = 20; } }
>
> void main()
> {
> C c = new C;
> printf("%d\n",c.i);
> foo!(C)(c);
> printf("%d\n",c.i);
> S s;
> printf("%d\n",s.i);
> foo!(S)(s);
> printf("%d\n",s.i);
> }
>
> One of Walter's goals is to make the compiler much easier to implement than C++,
> and I'm not sure if doing const param. checks would be one of the things that
> would severly impact achieving that goal.
>
> It *would* require a new mindset, but I think now's the time to try it out. It
> would be interesting to add (just) the C++-like const checks to the next build
> and have everyone run their code through it to see how much code it breaks (as
> in won't compile) and then regress if it causes too many problems. If it isn't
> too much effort for Walter, I think it'd be worth a try - this may well 'break'
> less code than changing AA's (as in the other current discussion) would.

Exactly!

Regan