Walter Bright Wrote:
> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
> 
> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

Perhaps I have missed the discussion (being away for the last 7 months) which discussed why we don't want 'scope const final' applied to implicit 'in' parameters?

As opposed to requiring explicit 'in' which Walter is proposing.

To explain...

Currently an parameter is implicitly 'in' i.e.
void foo(int a) {}  //a is 'in'

Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?

My reasoning is that I think 'scope const final' should be the default for parameters as it's the most commonly used and safest option for parameters.  People should use it by default/accident and should have to explicitly opt out in cases where it makes sense.  These cases would then be clearly, visibly marked with 'out', 'ref' etc

From what I can see we currently have 2 reasons to require explicit 'in' (from Walters post and others in this thread):

1. avoid breaking backward compatibility with D 1.0.

2. parameters will all have parameter specifiers and pedantic people (no offence intended) will enjoy fully specified function parameters all the time.

If so, isn't part of the point in making this change in a beta so that we can ignore reason #1.  Granted if the feature was to be integrated into the mainstream version it would then break backward compatibility, but, imagine the situation:

Old code would cease to compile and would need modification, but, the modifictions required would for the most part simply be the addition of 'out', 'ref', or an added .dup or copy.  Which, in actual fact should have been there in the first place.  Meaning, the exisiting code is unsafe and the resulting code after these changes would be much safer.

In other words, applying 'scope const final' to implicit 'in' will catch existing bugs, but requiring explicit 'in' will not, right?

As for reason #2 I think it's largely aesthetic however..

1. Applying it to implicit 'in' is less typing for those non-pedantic programmers who can live without all parameters having a specifier.  I personally dont think the presence of an explicit 'in' results in clearer code as it is clear to me that unspecified parameters are 'in' (and with these changes would be 'scope const final' too).

Regan Heath

I second that.
Make the safe thing the default, and the unsafe the explicit case.

Regan Heath wrote:
> Walter Bright Wrote:
> Perhaps I have missed the discussion (being away for the last 7 months) which discussed why we don't want 'scope const final' applied to implicit 'in' parameters?

Makes sense to me too.  I'd at least like to try it out for a few months and see how the shoe fits.  It seems to make a lot of sense.

I found this big thread about "const by default":
http://lists.puremagic.com/pipermail/digitalmars-d/2006-July/005626.html

--bb

I second this.

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.

Regan Heath wrote:

> Walter Bright Wrote:
>> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
>> 
>> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.
> 
> Perhaps I have missed the discussion (being away for the last 7 months) which discussed why we don't want 'scope const final' applied to implicit 'in' parameters?
> 
> As opposed to requiring explicit 'in' which Walter is proposing.
> 
> To explain...
> 
> Currently an parameter is implicitly 'in' i.e.
> void foo(int a) {}  //a is 'in'
> 
> Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?
> 
> My reasoning is that I think 'scope const final' should be the default for parameters as it's the most commonly used and safest option for parameters.  People should use it by default/accident and should have to explicitly opt out in cases where it makes sense.  These cases would then be clearly, visibly marked with 'out', 'ref' etc
> 
> From what I can see we currently have 2 reasons to require explicit 'in' (from Walters post and others in this thread):
> 
> 1. avoid breaking backward compatibility with D 1.0.
> 
> 2. parameters will all have parameter specifiers and pedantic people (no offence intended) will enjoy fully specified function parameters all the time.
> 
> If so, isn't part of the point in making this change in a beta so that we can ignore reason #1.  Granted if the feature was to be integrated into the mainstream version it would then break backward compatibility, but, imagine the situation:
> 
> Old code would cease to compile and would need modification, but, the modifictions required would for the most part simply be the addition of 'out', 'ref', or an added .dup or copy.  Which, in actual fact should have been there in the first place.  Meaning, the exisiting code is unsafe and the resulting code after these changes would be much safer.
> 
> In other words, applying 'scope const final' to implicit 'in' will catch existing bugs, but requiring explicit 'in' will not, right?
> 
> As for reason #2 I think it's largely aesthetic however..
> 
> 1. Applying it to implicit 'in' is less typing for those non-pedantic programmers who can live without all parameters having a specifier.  I personally dont think the presence of an explicit 'in' results in clearer code as it is clear to me that unspecified parameters are 'in' (and with these changes would be 'scope const final' too).
> 
> Regan Heath

I agree with this, const by default is a real good idea (TM)

Manuel König wrote:
> I second this.
> 
> 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.

Does nobody quote any more?  What are you seconding?

--bb

Bill Baxter wrote:
> Manuel König wrote:
>> I second this.
>>
>> 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.
> 
> Does nobody quote any more?  What are you seconding?
> 
> --bb

I'm seconding just the whole proposal. Quoting something didn't came to my because I'm not sticking to something in particular, but the whole thing :P

Anyhow, are there thoughts, comments by anyone who does/does not like the behaviour of omitting 'in' being 'scope const final'? Otherwise the 'in' behaviour proposed by Regan should really be part of the language, IMHO.

greetings,
manuel

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

Bill Baxter Wrote:
> Manuel König wrote:
> > I second this.
> > 
> > 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.
> 
> Does nobody quote any more?  What are you seconding?

Are you using a news reader which displays posts in threads?  When you're not it can be annoying to find a post with no quotation, I agree.

The web interface (which I am using until I have my own PC) seems to have trouble correctly threading all the posts too.  Opera didn't seem to have any trouble when I last used it.

I suspect either some of our newsreaders/posters do not correctly format the headers in replies and/or the web interface isn't looking for some headers which Opera did and/or there is some clever trick Opera was used to thread them correctly.

Anyway, enough rambling.  ;)

Regan Heath

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