preparing for const, final, and invariant

[Regan Heath]

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.

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.

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?

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?

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?

Regan Heath