preparing for const, final, and invariant

[Manuel König]

Regan Heath wrote:
> Manuel König Wrote:
>> Doing it this way 'in' also keeps its expressive character of saying 
>> "Hey, I am only the input and not that bunch of scope const final!", 
>> which especially makes sense when compared to 'out' in terms of data 
>> flow. And dismissing all of 'scope const final' just requires you to 
>> declare your params as 'in', which will rarely be the case.
> 
> To clarify, I was actually proposing that 'in' would be 'scope const final' and there would be no difference between explicit and implicit 'in'.
> 
> I think it's a bad idea to have implicit and explicit 'in' mean different things, it would just be confusing to me.
> 

Yes, difference between implicit/explicit 'in' can be confusing.

But that's only because we're used of data 'flowing in' to a function, 
and marking it 'out' if that's not the case. In fact, either 'in' or 
'out' are obligatory for every parameter (when in/out being considered 
as data flow). So you can say that only by accident 'in' became the 
default if not explicitly specified.

> That said, you could decide/declare that:
> 
>   void foo(int a) {}
> 
> was actually equivalent to:
> 
>   void foo(scope const final int a) {}
> 
> and that:
> 
>   void foo(in int a) {}
> 
> was something entirely different.

True.

> 
> In that case what do you want 'in' it to mean?  I get the impression you'd like it to behave as the current implicit/explicit 'in' does, right?
> 

Yes, I "like" it.

But I would put it more like 'in' and 'out' are two complementary 
attributes where one has to be present.

> My only question is, why do you want the current behaviour?  
> 
> I'm guessing you want to be able to do the things that 'scope const final' will protect against, but surely those things are dangerous and shouldn't be done?
> 

Yes, that's exactly what I want.

I think everyone can agree that 'scope' and 'const' are not everytime 
well appreciated. So the one left is the 'final' attribute.

Ok, I think I really can live with declaring my params 'final' when I 
don't want all the other things. But sometimes it would be nice if the 
parameter could be reassigned to something, like this:

void log(LogObject msg)
{
   msg.isLogged = true; // => no const
   lastLoggedMsg = msg; // => no scope

   // preprocessing => no final
   if (systemIsServer)
   {
     msg = "Server-log: " ~ msg;
   }
   else
   {
     msg = "Client-log: " ~ msg;
   }

   /* actually doing something with msg
    */
   writef(logfile, msg);
}

Here msg gets preprocessed first, and than used by whatever you want (in 
this case it gets logged).

If you could not rebind 'msg' to another symbol, you would have to 
declare a new variable, think of a new name for it, eg. 'msg_ex', and 
finally assign it to the preprocessing results. But that seems to me 
like a workaround that you can't just reassign 'msg' and it also bloats 
your code.

   Not too much an argument? Declaring new variables really isn't that 
bad compared to all the issues you trouble into when code gets rewritten 
and suddenly something does not work because you assign to a renamed 
parameter that was a local variable before?

Ok, I hear you. May be 'in' being 'scope final const' isn't that bad at 
all :). I'm just being stuck with 'in' not only meaning the data flow.


In the end I would prefer 'in' being only 'in' a little bit over 'scope 
final const (in)' because there seems to be no reason for me using 'in' 
when I have the opportunity to just write nothing. And when I would use 
'in' I would seriously know what I'm typing there! But that's only my 
personal opinion.

I would be totally fine at all with 'in' meaning 'scope const final'.

> Is there a specific case you are thinking of where you need to do these things?  One where there is no decent work-around in the presense of 'scope const final' as default?
> 

Look above. (ok, there actually IS a decent work-around... :) )

> Regan Heath