www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Would like to see ref and out required for function calls

reply "Kevin McTaggart" <kevin.mctaggart drdc-rddc.gc.ca> writes:
I've been looking at migrating a reasonably large ship motion 
library (tens of thousands of lines) from C# to D.  I've become 
quite enthusiastic about D, and most of my problems have been 
relatively minor (e.g., inconsistent bugs with 
std.container.Array, would like orange serialization to give me 
an error telling me I didn't register a class before calling 
serialize).  I suggest that the language require ref and out when 
calling functions, as C# requires.  This would make code easier 
to understand, and would also eliminate the problem I had when 
the wrong function from the following choices was mistakenly 
called:

parseLineInts(string text, int positionStart, out int j0, out int 
j1)

parseLineInts(string text, out int j0, out int j1, out int j2)

I note that the second function calls another function as follows:
int positionStart = 1;
parseLineInts(text, positionStart, j0, j1, j2);

I look forward to seeing feedback from D experts.  This is the 
only significant change that I could think of recommending for 
the language.
Sep 07 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/7/12 1:34 PM, Kevin McTaggart wrote:
 I've been looking at migrating a reasonably large ship motion library
 (tens of thousands of lines) from C# to D. I've become quite
 enthusiastic about D, and most of my problems have been relatively minor
 (e.g., inconsistent bugs with std.container.Array, would like orange
 serialization to give me an error telling me I didn't register a class
 before calling serialize). I suggest that the language require ref and
 out when calling functions, as C# requires. This would make code easier
 to understand, and would also eliminate the problem I had when the wrong
 function from the following choices was mistakenly called:

 parseLineInts(string text, int positionStart, out int j0, out int j1)

 parseLineInts(string text, out int j0, out int j1, out int j2)

 I note that the second function calls another function as follows:
 int positionStart = 1;
 parseLineInts(text, positionStart, j0, j1, j2);

 I look forward to seeing feedback from D experts. This is the only
 significant change that I could think of recommending for the language.

Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. Andrei
Sep 07 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/7/12 4:55 PM, Andrej Mitrovic wrote:
 On 9/7/12, Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 Actually the darndest thing is that C# has retired the syntax in 5.0 (it
 used to be required up until 4.0). Apparently users complained it was
 too unsightly.

If you like implicit ref then why did you choose to use pointers when implementing std.getopt?

At the time ref variadics weren't implemented. I should also add I joined D after ref was there. I don't have strong feelings one way or another. Andrei
Sep 07 2012
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 07.09.2012 16:38, schrieb Andrei Alexandrescu:
 Actually the darndest thing is that C# has retired the syntax in 5.0 (it
 used to be required up until 4.0). Apparently users complained it was
 too unsightly.

reference link?
Sep 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/07/2012 04:38 PM, Andrei Alexandrescu wrote:
 ...
 Actually the darndest thing is that C# has retired the syntax in 5.0 (it
 used to be required up until 4.0). Apparently users complained it was
 too unsightly.

 Andrei

How do they deal with the increased ambiguity in overload resolution?
Sep 07 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/07/2012 05:51 PM, Timon Gehr wrote:
 How do they deal with the increased ambiguity in overload resolution?

Actually, it is simple. They just have to call the non-out overload when there is no out at the call site, regardless of the actual argument.
Sep 07 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/7/12, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Actually the darndest thing is that C# has retired the syntax in 5.0 (it
 used to be required up until 4.0). Apparently users complained it was
 too unsightly.

If you like implicit ref then why did you choose to use pointers when implementing std.getopt?
Sep 07 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, September 07, 2012 13:34:02 Kevin McTaggart wrote:
 I look forward to seeing feedback from D experts.  This is the
 only significant change that I could think of recommending for
 the language.

Regardless of the pros and cons of requiring explicit ref and out, it would break a lot of code if we started requiring it, so I don't think that there's any chance of such a change being made at this point. If/When we create D3 (which is years off), it could be discussed and possibly changed then, but I think that it's clearly too large a change for D2 at this point. - Jonathan M Davis
Sep 07 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Actually the darndest thing is that C# has retired the syntax 
 in 5.0 (it used to be required up until 4.0). Apparently users 
 complained it was too unsightly.

Are you sure? This page about the Visual Studio 2012 shows that ref and out are required: http://msdn.microsoft.com/en-us/library/14akc2c7.aspx I know they have relaxed the requirement in one case, in C#4 or something. The idea of requiring ref/out at the all site was discussed some times in past. This idea has both advantages and disadvantages. It makes the code a bit longer, but gives the reader more information about what the call will do. In D there are also ref at the return value, I presume this is never going to require a "ref" at the call site. Bye, bearophile
Sep 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 7 September 2012 at 16:46:36 UTC, bearophile wrote:
 Andrei Alexandrescu:

 Actually the darndest thing is that C# has retired the syntax 
 in 5.0 (it used to be required up until 4.0). Apparently users 
 complained it was too unsightly.

Are you sure? This page about the Visual Studio 2012 shows that ref and out are required: http://msdn.microsoft.com/en-us/library/14akc2c7.aspx

+1
Sep 07 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-09-07 13:34, Kevin McTaggart wrote:
 I've been looking at migrating a reasonably large ship motion library
 (tens of thousands of lines) from C# to D.  I've become quite
 enthusiastic about D, and most of my problems have been relatively minor
 (e.g., inconsistent bugs with std.container.Array, would like orange
 serialization to give me an error telling me I didn't register a class
 before calling serialize).

Please report any bugs about Orange to https://github.com/jacob-carlborg/orange and I'll see what I can do about it. -- /Jacob Carlborg
Sep 07 2012
prev sibling next sibling parent reply "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
Given:

void func (ref int[], int)

If ref/out were required at the call site, this destroys UFCS.

int[] array;
array.func(0); // error, ref not specified by caller

Or would one expect something like:

(ref array).func(0);

...put simply, I hope not.

This suggestion has come up a couple times before, and each time 
failed to gain traction.  I wouldn't mind it as an option -- 
possibly even as a recommendation in most library code -- but as 
a requirement it honestly just gives me a headache.  Generally 
speaking, if a parameter being ref/out is surprising, there is 
something wrong with the design.  (There are times it is 
non-obvious in otherwise good code, this seems uncommon.)

For example, calling one of the *InPlace functions from Phobos, I 
immediately expect 'ref' -- otherwise, how to modify "in place" 
in a reliable (ie, non-allocating) manner?  Likewise, 'out' -- 
used pretty rarely in the first place -- sits in the same place 
pointers typically do, as auxiliary returns.  The category of 
functions/methods which use them is pretty self consistent.  
(What few corner cases remain would be better served by cleaning 
up tuples to make them more sane as return values.)

Given:

bool checkedEmitJ (Op, Params, ref const(Scope), Address, out 
Address)

I really don't want to have to call it as:

auto handled = checkedEmitJ(Op.CJmp, parms, ref _scope, suggest, 
out lval);

When the 'ref' and 'out' parameters listed are specified by the 
design and consistent across all the "-emit-" functions.
Sep 08 2012
parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
 Given:

 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied. Also for 'const ref' parameters, callsite ref should not be necessary.
 This suggestion has come up a couple times before, and each time failed
 to gain traction.

But given that C, C#, (Go?) and Rust have the same philosophy that argument modification should be explicit for value types, it is arguably important. It might be nice to have for D3.
 I wouldn't mind it as an option -- possibly even as a
 recommendation in most library code -- but as a requirement it honestly
 just gives me a headache.

As an option it would serve no practical purpose other than documentation.
 Generally speaking, if a parameter being
 ref/out is surprising, there is something wrong with the design.  (There
 are times it is non-obvious in otherwise good code, this seems uncommon.)

Yes but unfortunately bad design is going to be a reality sometimes. Also there is a difference between 'surprising' and 'obvious'. Callsite ref makes it quicker to understand code for a negligible cost, occasionally a lot quicker if you're coming back to code you haven't seen for a while.
 For example, calling one of the *InPlace functions from Phobos, I
 immediately expect 'ref' -- otherwise, how to modify "in place" in a
 reliable (ie, non-allocating) manner?  Likewise, 'out' -- used pretty
 rarely in the first place -- sits in the same place pointers typically
 do, as auxiliary returns.  The category of functions/methods which use
 them is pretty self consistent. (What few corner cases remain would be
 better served by cleaning up tuples to make them more sane as return
 values.)

 Given:

 bool checkedEmitJ (Op, Params, ref const(Scope), Address, out Address)

 I really don't want to have to call it as:

 auto handled = checkedEmitJ(Op.CJmp, parms, ref _scope, suggest, out lval);

 When the 'ref' and 'out' parameters listed are specified by the design
 and consistent across all the "-emit-" functions.

The point is that the signature of checkedEmitJ is not always there when you are reading code that calls checkedEmitJ, so the ref and out parameters are useful in saving the reader time. Making code easier to read is much more important than making it easier to write. When I first saw: swap(ref a, ref b); I thought that looked ugly with the refs, but now I don't mind it. IMO it's only functions whose arguments are all passed by ref that don't really need annotation, and these are infrequent. All others stand to benefit.
Sep 08 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
Agh, sent a private mail again. I don't seem to be the only one though.
Has there been a thunderbird UI change?

On 09/08/2012 06:05 PM, Nick Treleaven wrote:
 On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
 Given:

 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.

Why? UFCS means uniform function call syntax.
 Also for 'const ref' parameters, callsite ref should not be necessary.

The callee might escape a pointer to the argument. Which is 'non-obvious' as well when there is no callsite ref.
 This suggestion has come up a couple times before, and each time failed
 to gain traction.

But given that C, C#, (Go?) and Rust have the same philosophy that argument modification should be explicit

It is already explicit. The information is just not repeated at the call site.
 for value types, it is arguably important.

This is not necessarily a valid conclusion. Popularity does not imply importance.
 It might be nice to have for D3.

 I wouldn't mind it as an option -- possibly even as a
 recommendation in most library code -- but as a requirement it honestly
 just gives me a headache.

As an option it would serve no practical purpose other than documentation.

Requiring it makes lack of call site annotations carry some information. The only practical purpose would still be documentation.
 Generally speaking, if a parameter being
 ref/out is surprising, there is something wrong with the design.  (There
 are times it is non-obvious in otherwise good code, this seems uncommon.)

Yes but unfortunately bad design is going to be a reality sometimes.

Bad design never should be a motivation for adding language features. In fact, it seems to be a motivation for creating languages that have few features.
 Also there is a difference between 'surprising' and 'obvious'. Callsite
 ref makes it quicker to understand code for a negligible cost,
 occasionally a lot quicker if you're coming back to code you haven't
 seen for a while.

IMHO it is better left to the future D editor. It can highlight ref/out arguments in a distinct style. Why clutter the language core even more with somewhat complex rules specifying in what cases call site ref is required?
 ...
 The point is that the signature of checkedEmitJ is not always there when
 you are reading code that calls checkedEmitJ, so the ref and out
 parameters are useful in saving the reader time.

I'd still have to look up its declaration to understand exactly what it does.
 Making code easier to read is much more important than making it easier to
write.

I don't know why this quote is repeated all the time. It is not like ease of writing and ease of reading are decoupled or something. What is most important is designing the language such that code that is easy to write is easy to read. What is easy to read is to some extent subjective. eg. I'd prefer to just look at the called function's documentation rather than having every call I later inspect redundantly repeat information present in the function declaration. IMHO it's just noise.
 When I first saw:
 swap(ref a, ref b);

 I thought that looked ugly with the refs, but now I don't mind it. IMO
 it's only functions whose arguments are all passed by ref that don't
 really need annotation,

We are talking about call site annotations. Functions will always require annotation to change the parameter passing style.
 and these are infrequent.

What is this claim based on? The use case above is probably one of the more common ones.
Sep 08 2012
next sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 08/09/2012 19:17, Timon Gehr wrote:
 On 09/08/2012 06:05 PM, Nick Treleaven wrote:
 On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
 Given:

 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.

Why? UFCS means uniform function call syntax.

I meant if callsite ref was required for parameters, it should not be required for array in 'array.func()'. It would be bizarre to require '(ref array).func()'.
 Also for 'const ref' parameters, callsite ref should not be necessary.

The callee might escape a pointer to the argument. Which is 'non-obvious' as well when there is no callsite ref.

Knowing modification is more important to the local scope than knowing escapes, after all (in theory) the compiler should enforce that only data safe to be escaped is allowed to be escaped, at least in safe mode. In any case, escaping is orthogonal to modification, so shouldn't use 'ref'.
 This suggestion has come up a couple times before, and each time failed
 to gain traction.

But given that C, C#, (Go?) and Rust have the same philosophy that argument modification should be explicit

It is already explicit. The information is just not repeated at the call site.

It is not explicit at the call site. That is the crux of the argument for the feature.
 for value types, it is arguably important.

This is not necessarily a valid conclusion. Popularity does not imply importance.

I only said it was *arguably* important, given that the parent post said the idea failed to gain traction. Go and Rust are relatively new and decided for the explicit callsite approach (AFAIU).
 It might be nice to have for D3.


BTW if this was desired (and it seems a long shot ATM) I was thinking there should be an automatic tool to upgrade code from D2 to D3.
 I wouldn't mind it as an option -- possibly even as a
 recommendation in most library code -- but as a requirement it honestly
 just gives me a headache.

As an option it would serve no practical purpose other than documentation.

Requiring it makes lack of call site annotations carry some information. The only practical purpose would still be documentation.

Yes, albeit compiler enforced documentation.
 Generally speaking, if a parameter being
 ref/out is surprising, there is something wrong with the design.  (There
 are times it is non-obvious in otherwise good code, this seems
 uncommon.)

Yes but unfortunately bad design is going to be a reality sometimes.

Bad design never should be a motivation for adding language features. In fact, it seems to be a motivation for creating languages that have few features.

OK, but ref/out parameters aren't always a bad design.
 Also there is a difference between 'surprising' and 'obvious'. Callsite
 ref makes it quicker to understand code for a negligible cost,
 occasionally a lot quicker if you're coming back to code you haven't
 seen for a while.

IMHO it is better left to the future D editor. It can highlight ref/out arguments in a distinct style. Why clutter the language core even more with somewhat complex rules specifying in what cases call site ref is required?

1. Unix tools will never highlight ref/out parameters - e.g. grep. 2. Github probably won't ever. 3. Not everyone will use an editor that does so. Some people prefer a simple editor.
 ...
 The point is that the signature of checkedEmitJ is not always there when
 you are reading code that calls checkedEmitJ, so the ref and out
 parameters are useful in saving the reader time.

I'd still have to look up its declaration to understand exactly what it does.

Sometimes you're not concerned with the precise effect of a function, you just want to work out how it impacts the surrounding code.
 Making code easier to read is much more important than making it
 easier to write.

I don't know why this quote is repeated all the time. It is not like ease of writing and ease of reading are decoupled or something. What is most important is designing the language such that code that is easy to write is easy to read. What is easy to read is to some extent subjective. eg. I'd prefer to just look at the called function's documentation rather than having every call I later inspect redundantly repeat information present in the function declaration. IMHO it's just noise.

It would likely become a motor-skill to ignore the keywords when you're not interested in them.
 When I first saw:
 swap(ref a, ref b);

 I thought that looked ugly with the refs, but now I don't mind it. IMO
 it's only functions whose arguments are all passed by ref that don't
 really need annotation,

We are talking about call site annotations. Functions will always require annotation to change the parameter passing style.

Can't disagree there ;-)
 and these are infrequent.

What is this claim based on? The use case above is probably one of the more common ones.

How often do you use swap?
Sep 09 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/09/2012 02:54 PM, Nick Treleaven wrote:
 On 08/09/2012 19:17, Timon Gehr wrote:
 On 09/08/2012 06:05 PM, Nick Treleaven wrote:
 On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
 Given:

 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.

Why? UFCS means uniform function call syntax.

I meant if callsite ref was required for parameters, it should not be required for array in 'array.func()'. It would be bizarre to require '(ref array).func()'.

Not more bizarre as in other positions.
...
 This is not necessarily a valid conclusion. Popularity does not imply
 importance.

I only said it was *arguably* important, given that the parent post said the idea failed to gain traction. Go and Rust are relatively new and decided for the explicit callsite approach (AFAIU).

Yes, Go uses explicit pointer types. Regarding Rust, you are wrong. I have built the latest Rust compiler. import io; fn modify(&a:int){ a = 2; } fn swap<T>(&a:T,&b:T){ let tmp<-a; a<-b; b<-tmp; } fn main(){ let mut a= 1; io::println(fmt!("%d",a)); // "1" modify(a); io::println(fmt!("%d",a)); // "2" let mut b=2, c=3; io::println(fmt!("%d %d",b,c)); // "2 3" swap(b,c); io::println(fmt!("%d %d",b,c)); // "3 2" let mut f = fn (a:int)->int{ a + 1 }; let mut g = fn (a:int)->int{ a - 1 }; io::println(fmt!("%d %d",f(2),g(2))); // "3 1" swap(f,g); io::println(fmt!("%d %d",f(2),g(2))); // "1 3" }
 ...
 What is this claim based on? The use case above is probably one of the
 more common ones.

How often do you use swap?

Whenever I want to swap the values of two variables. All other functions in my current project except one that use ref either pass by const/immutable ref, or all arguments are ref, or they are function pointer literals that are part of a polymorphic value type where it is obvious that the first parameter is passed by ref. The remaining function is private and declared right between the methods that use it.
Sep 10 2012
next sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 10/09/2012 21:36, Timon Gehr wrote:
 On 09/09/2012 02:54 PM, Nick Treleaven wrote:
 On 08/09/2012 19:17, Timon Gehr wrote:
 On 09/08/2012 06:05 PM, Nick Treleaven wrote:
 On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
 Given:

 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.

Why? UFCS means uniform function call syntax.

I meant if callsite ref was required for parameters, it should not be required for array in 'array.func()'. It would be bizarre to require '(ref array).func()'.

Not more bizarre as in other positions.

The brackets make it more ugly though. The reason why it is not necessary is that in general, function arguments are not implicitly modified (and some languages enforce this). But when you see foo.bar() and you don't know what bar does, you don't assume that foo won't be modified, even across many languages.
 This is not necessarily a valid conclusion. Popularity does not imply
 importance.

I only said it was *arguably* important, given that the parent post said the idea failed to gain traction. Go and Rust are relatively new and decided for the explicit callsite approach (AFAIU).

Yes, Go uses explicit pointer types. Regarding Rust, you are wrong.

OK, I misunderstood Rust & I apologize. Thanks for providing the example code.
 What is this claim based on? The use case above is probably one of the
 more common ones.

How often do you use swap?

Whenever I want to swap the values of two variables. All other functions in my current project except one that use ref either pass by const/immutable ref, or all arguments are ref, or they are function pointer literals that are part of a polymorphic value type where it is obvious that the first parameter is passed by ref. The remaining function is private and declared right between the methods that use it.

Then callsite ref might not help you at all. I think Manuel's recent post is better than anything I could write to support the idea.
Sep 11 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/18/2012 11:26 PM, Ziad Hatahet wrote:
 On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr <timon.gehr gmx.ch
 <mailto:timon.gehr gmx.ch>> wrote:


     Yes, Go uses explicit pointer types.
     Regarding Rust, you are wrong.
     I have built the latest Rust compiler.

     import io;

     fn modify(&a:int){
          a = 2;
     }
     fn swap<T>(&a:T,&b:T){
         let tmp<-a;
         a<-b;
         b<-tmp;
     }


 The `fn foo(&a: T)` syntax is being deprecated in favor of `fn foo(a:
 &mut T)`.

 So your modify function becomes: `fn modify(a: &mut int)`, and gets
 called as `modify(&mut a)`.

 Your swap function becomes `fn swap<T>(a: &mut T, b: &mut T)` and gets
 called as `swap(&mut a, &mut b)`.

 So effectively, Rust also opted for explicit ref at the call site.

 --
 Ziad

I see. Thank you for the clarification.
Sep 19 2012
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 08.09.2012 20:17, schrieb Timon Gehr:
 Agh, sent a private mail again. I don't seem to be the only one though.
 Has there been a thunderbird UI change?
 

They exchanged the order of the "Reply" and "Smart reply" buttons in TB 15. This also hit me several times, very annoying. You can switch them back using "Customize" in the context menu though.
Sep 11 2012
prev sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 11/09/2012 18:57, David Piepgrass wrote:
 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.


 Why? UFCS means uniform function call syntax.

reference: struct Foo { int x = 0; void f() { x++; } } void obvious() { Foo foo; foo.f(); // x is passed to f() by reference } Perhaps your argument makes sense for classes, but not for structs. In any case the syntax (ref foo).f() would require extra work for Walter so I would not propose it. What I might propose instead is that, if the user requests (via command-line argument such as '-callSiteRef') that a warning be issued for arguments passed without 'ref' at the call site, then a situation like this should prompt a warning. class Bar { int b; } void changeBar(ref Bar b) { b = new Bar(); } void warning() { Bar bar = new Bar(); bar.b = 10; bar.changeBar(); // Warning: 'bar' is implicitly passed by reference. To eliminate this warning, use 'changeBar(ref bar)' instead or do not compile with '-callSiteRef' } Again, this problem only applies to classes, since it is understood that structs are normally passed by reference.

I had only thought about UFCS and ref parameters for value types. You are right that requiring callsite ref for class ref parameters would be a useful idea, as modifying the ref itself is unusual behavior. And because of that, disallowing UFCS for functions that have a class ref parameter as the first parameter might be an elegant solution.
Sep 12 2012
parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 12/09/2012 13:39, Nick Treleaven wrote:
 class Bar { int b; }
 void changeBar(ref Bar b) { b = new Bar(); }
 void warning()
 {
      Bar bar = new Bar();
      bar.b = 10;
      bar.changeBar(); // Warning: 'bar' is implicitly passed by
 reference. To eliminate this warning, use 'changeBar(ref bar)' instead
 or do not compile with '-callSiteRef'
 }

 Again, this problem only applies to classes, since it is understood that
 structs are normally passed by reference.

I had only thought about UFCS and ref parameters for value types. You are right that requiring callsite ref for class ref parameters would be a useful idea, as modifying the ref itself is unusual behavior. And because of that, disallowing UFCS for functions that have a class ref parameter as the first parameter might be an elegant solution.

Also the same applies to ref parameters with any reference types: On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

So the above poster was right, I completely missed this :-/ (But disallowing UFCS here still might be a good solution).
Sep 12 2012
parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 12/09/2012 13:55, Nick Treleaven wrote:
 On 12/09/2012 13:39, Nick Treleaven wrote:
 class Bar { int b; }
 void changeBar(ref Bar b) { b = new Bar(); }
 void warning()
 {
      Bar bar = new Bar();
      bar.b = 10;
      bar.changeBar(); // Warning: 'bar' is implicitly passed by
 reference. To eliminate this warning, use 'changeBar(ref bar)' instead
 or do not compile with '-callSiteRef'
 }

 Again, this problem only applies to classes, since it is understood that
 structs are normally passed by reference.

I had only thought about UFCS and ref parameters for value types. You are right that requiring callsite ref for class ref parameters would be a useful idea, as modifying the ref itself is unusual behavior. And because of that, disallowing UFCS for functions that have a class ref parameter as the first parameter might be an elegant solution.

Also the same applies to ref parameters with any reference types: On 08/09/2012 14:05, Chris Nicholson-Sauls wrote: > void func (ref int[], int) > > If ref/out were required at the call site, this destroys UFCS. > > int[] array; > array.func(0); // error, ref not specified by caller So the above poster was right

Ignore that last reply, slices are value types. The syntax array.func() looks like it might modify array's contents and/or length, so UFCS is OK. It is only ref class and ref pointer arguments that UFCS should be disallowed on to enforce call-site ref.
Sep 14 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Treleaven:

 IMO it's only functions whose arguments are all passed by ref 
 that don't really need annotation, and these are infrequent. 
 All others stand to benefit.

For arguments that use "const ref", "in ref", "immutable ref" I think ref at the call site is not so important. Bye, bearophile
Sep 08 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
On Friday, 7 September 2012 at 11:33:41 UTC, Kevin McTaggart 
wrote:
 I've been looking at migrating a reasonably large ship motion 
 library (tens of thousands of lines) from C# to D.  I've become 
 quite enthusiastic about D, and most of my problems have been 
 relatively minor (e.g., inconsistent bugs with 
 std.container.Array, would like orange serialization to give me 
 an error telling me I didn't register a class before calling 
 serialize).  I suggest that the language require ref and out 
 when calling functions, as C# requires.  This would make code 
 easier to understand, and would also eliminate the problem I 
 had when the wrong function from the following choices was 
 mistakenly called:

 parseLineInts(string text, int positionStart, out int j0, out 
 int j1)

 parseLineInts(string text, out int j0, out int j1, out int j2)

 I note that the second function calls another function as 
 follows:
 int positionStart = 1;
 parseLineInts(text, positionStart, j0, j1, j2);

 I look forward to seeing feedback from D experts.  This is the 
 only significant change that I could think of recommending for 
 the language.

+1. The fact that a value type is modified should be information the programmer can see at a glance. Andrei Alexandrescu wrote:
 Actually the darndest thing is that C# has retired the syntax 
 in 5.0 (it used to be required up until 4.0). Apparently users 
 complained it was too unsightly.

Citation? I'm using C# 5.0 with Visual Studios 2012 on Windows 8 right now and ref/out are still required at the call sight of functions.
Sep 08 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 11-09-2012 06:21, zerg wrote:
 But i have to admit, that it might be too late for changes in D2

Such feature can be implemented as optional in D2 with compiler switch to enforce explicit ref and out syntax.

It's already highly problematic that we have -property (and that it isn't the default). D code shouldn't stop being valid just because of a missing compiler switch (or the presence of one). -- Alex Rønne Petersen alex lycus.org http://lycus.org
Sep 10 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/11/12 1:28 AM, Manuel wrote:
 Citation? I'm using C# 5.0 with Visual Studios 2012 on Windows 8 right
 now and ref/out are still required at the call sight of functions.

I have Visual Studio 2012 RC and can confirm, that ref and out are still required even with C# 5.0 (but maybe there is some compiler switch to disable this ??)

Erik Meijer didn't get back to me yet about that with a link, but he did mention that the relaxation was only allowed for COM calls. Andrei
Sep 11 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/12 1:02 AM, Manuel wrote:
 If a bigger part of the D community would like to have these annotations
 added to the language, at least as an optional feature, then that might
 persuade our "benevolent dictators" (just joking - you are great!)
 Walther and Andrei to add them or we could just make a fork of the
 language and add them ourselves (more joking - no, just skip this last
 part - it's late) :-)

 There might be other problems, maybe with the compiler internals or
 breakage of parts of the language. These were severe. But i think only
 Walther and Andrei might tell. If these wouldn't exist it would at least
 be possible, how David proposed it in his post, to make them optional.

I don't think there would be problems with allowing ref/out optionally at the call site. The thing is, however, that in this matter reasonable people may disagree. In C++, the equivalent argument (should we pass everything modifiable by pointer or not?) erupts every six months on internal fora at Facebook. No winning argument is made by either part. For example, it is often brought up that it's good to see "&" at the call site when debugging some urgent matter at 3am. Yet there are other people who are just as apt at debugging urgent matters at 3am, and the absence of "&" doesn't seem to be a handicap for them at all. I'd be unable to identify any pattern in engineers choosing one preference over the other. As a consequence, our code has a mix of pass-by-pointer and pass-by-reference-to-nonconst, all engineers manage either style just as well, and we've never been able to find any evidence pointing one way or another. Now that the subject has been broken, we do have good evidence of a pattern that generates significant and difficult bugs: escaping the address of a reference. In C++: struct A { A(int& host) : host_(host) {} private: int& host_; }; In D: class A { // or struct A(ref int host) : _host(&host) {} private: int* _host; } A solution we use for C++ is to require escaped addresses to be always passed as pointers or smart pointers. Walter and I have discussed this for quite a while. We have recently decided to disallow, at least in SafeD, escaping the address of a ref parameter. In the beginning we'll be overly conservative by disallowing taking the address of a ref altogether. I'll write a DIP on that soon. Andrei
Sep 13 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/12 6:58 AM, Namespace wrote:
 In D:

 class A { // or struct
 A(ref int host) : _host(&host) { }
 private:
 int* _host;
 }

 Since when do we have initialization lists in D? ;)

Oops, sorry :o).
 at topic: +1

One question Walter and I thought about a lot was whether we should disallow escaping addresses of ref parameters in general or only in safe code. We decided to go for the latter in order to avoid breakage of existing code. Thoughts? Andrei
Sep 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-13 18:28, Sean Kelly wrote:

 I love the idea.  However, this could complicate working with C APIs,
particularly regarding structs which are often passed by reference as a matter
of course.  For example:

 struct some_c_struct {}

 void fn(ref some_c_struct s) {
      some_c_func(&s);
 }

 I guess the only way to know if this will turn out to be a real issue is to
give it a try though.

This applies to static arrays as well: extern (C) void foo (ref int[3] a); Since in D static arrays have value semantics. -- /Jacob Carlborg
Sep 13 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/12 10:53 AM, David Piepgrass wrote:
 Walter and I have discussed this for quite a while. We have recently
 decided to disallow, at least in SafeD, escaping the address of a ref
 parameter. In the beginning we'll be overly conservative by
 disallowing taking the address of a ref altogether. I'll write a DIP
 on that soon.

Err, wouldn't that break a lot of stuff, a lot of which is actually safe code? void a(ref int x) { b(&x); } void b(int* x) { if(x != null) (*x)++; }

Yes. Disallowing taking the address of a local is conservative and would disallow a number of valid programs. Arguably, such programs are in poor style anyway. A good program takes pointers only if it needs to keep them around; if all that's needed is to use the parameter transitorily or pass it down, ref is best.
 Escaping the addresses of stack variables, not just ref parameters, is a
 general problem in "safe" D. Do you have any ideas about that?

Same thing. By and large safe programs will need to make more use of the garbage collector than others. It's the way things work; stack allocation can be made safer if we add typed regions, but that's a very significant escalation of complication. There is no simple solution to this today. Andrei
Sep 13 2012
parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 13/09/2012 16:29, David Piepgrass wrote:
 On Thursday, 13 September 2012 at 15:01:28 UTC, Andrei Alexandrescu wrote:
 On 9/13/12 10:53 AM, David Piepgrass wrote:
 Walter and I have discussed this for quite a while. We have recently
 decided to disallow, at least in SafeD, escaping the address of a ref
 parameter. In the beginning we'll be overly conservative by
 disallowing taking the address of a ref altogether. I'll write a DIP
 on that soon.

Err, wouldn't that break a lot of stuff, a lot of which is actually safe code? void a(ref int x) { b(&x); } void b(int* x) { if(x != null) (*x)++; }

Yes. Disallowing taking the address of a local is conservative and would disallow a number of valid programs.


What about: void b(scope int* x) { if(x != null) (*x)++; } Then 'a' could compile safely.
 Arguably, such programs are in poor style anyway. A good program takes
 pointers only if it needs to keep them around; if all that's needed is
 to use the parameter transitorily or pass it down, ref is best.

Another common reason to use a pointer (instead of ref) is if it's optional (nullable). If the parameter is ref then the caller must go to the trouble of creating a variable.

Maybe std.typecons.Nullable or something like it helps there.
Sep 14 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/12 11:47 AM, David Piepgrass wrote:
 I really think that optionally allowing ref and out at the call site
 is more
 damaging than beneficial. _Requiring_ it could be beneficial, since
 then you
 know that the arguments are being taken by ref, but if it's optional,
 it gives
 you a false sense of security and can be misleading.

It gives *who* a false sense of security?

It's "whom". Andrei P.S. All of my life I've been waiting for this moment!!!
Sep 13 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, September 08, 2012 17:05:25 Nick Treleaven wrote:
 As an option it would serve no practical purpose other than documentation.

It's worse than that. It's not even documentation that you can trust. If it were optional, and ref were used in a function call, then you know that the argument is being passed by ref (since presumably, you'll get a compilation error if it's not), but if there is no ref, it tells you _nothing_. It could be ref, but it might not be. And if you used ref at the call site frequently, then the lack of ref would end up giving the false impression that the argument wasn't being passed by ref in the case where the ref was forgotten. There's some argument for requiring it (though at this point in its development, I think that it's too late to make it required even if it were determined that that were desirable), but making it optional is _definitely_ a bad idea IMHO. - Jonathan M Davis
Sep 08 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 07 Sep 2012 13:34:02 +0200
"Kevin McTaggart" <kevin.mctaggart drdc-rddc.gc.ca> wrote:

 I suggest that the language require ref and out when 
 calling functions, as C# requires.

That's one thing I've always thought C# got better than D. I'd love to see D fixed in this regard, and I've argued in favor of it some time ago. Unfortunately I don't think it's going to happen. Certainly not for D2 anyway, it's too late :(
Sep 08 2012
prev sibling next sibling parent "Manuel" <manuel test.es> writes:
On Saturday, 8 September 2012 at 17:20:21 UTC, F i L wrote:
 On Friday, 7 September 2012 at 11:33:41 UTC, Kevin McTaggart 
 wrote:
 I've been looking at migrating a reasonably large ship motion 
 library (tens of thousands of lines) from C# to D.  I've 
 become quite enthusiastic about D, and most of my problems 
 have been relatively minor (e.g., inconsistent bugs with 
 std.container.Array, would like orange serialization to give 
 me an error telling me I didn't register a class before 
 calling serialize).  I suggest that the language require ref 
 and out when calling functions, as C# requires.  This would 
 make code easier to understand, and would also eliminate the 
 problem I had when the wrong function from the following 
 choices was mistakenly called:

 parseLineInts(string text, int positionStart, out int j0, out 
 int j1)

 parseLineInts(string text, out int j0, out int j1, out int j2)

 I note that the second function calls another function as 
 follows:
 int positionStart = 1;
 parseLineInts(text, positionStart, j0, j1, j2);

 I look forward to seeing feedback from D experts.  This is the 
 only significant change that I could think of recommending for 
 the language.

+1. The fact that a value type is modified should be information the programmer can see at a glance.

+1 here too. Coming from C# this is exactly what i was missing from D too. It's not only that the information that a value type is modified should be visible to the programmer at a glance who had originally written the code but also to other team members who just want to do a quick read over code someone else has written or to the people who do code review. From my personal experience within commercial software development code is much more often read than written. And most of the time it will be read by a larger amount of people one can initially think of. But i have to admit, that it might be too late for changes in D2 regarding this just because it would break too much existing code (and at the moment code still breaks too often).
 Andrei Alexandrescu wrote:
 Actually the darndest thing is that C# has retired the syntax 
 in 5.0 (it used to be required up until 4.0). Apparently users 
 complained it was too unsightly.


I have never heard anyone complaining about this syntax nor have i read of anyone complaining about this online in newsgroups or such. From my colleagues and my circle of acquaintances only former C++ programmers were initially complaining but they were soon adopting this syntax and at the end they had to admit that these additional syntax annotations at the call site make sense. I think ref/out is like the now "forced" "override" keyword for overridden methods - it just helps to avoid mistakes and makes things a little bit safer.
 Citation? I'm using C# 5.0 with Visual Studios 2012 on Windows 
 8 right now and ref/out are still required at the call sight of 
 functions.

I have Visual Studio 2012 RC and can confirm, that ref and out are still required even with C# 5.0 (but maybe there is some compiler switch to disable this ??)
Sep 10 2012
prev sibling next sibling parent "zerg" <Sergey.Chelombitko gmail.com> writes:
 But i have to admit, that it might be too late for changes in D2

Such feature can be implemented as optional in D2 with compiler switch to enforce explicit ref and out syntax.
Sep 10 2012
prev sibling next sibling parent "Manuel" <manuel d.org> writes:
On Tuesday, 11 September 2012 at 08:10:21 UTC, Andrei 
Alexandrescu wrote:
 On 9/11/12 1:28 AM, Manuel wrote:
 Citation? I'm using C# 5.0 with Visual Studios 2012 on 
 Windows 8 right
 now and ref/out are still required at the call sight of 
 functions.

I have Visual Studio 2012 RC and can confirm, that ref and out are still required even with C# 5.0 (but maybe there is some compiler switch to disable this ??)

Erik Meijer didn't get back to me yet about that with a link, but he did mention that the relaxation was only allowed for COM calls. Andrei

OK, i see. For COM calls that might make sense, since binary COM modules are mostly written in C/C++ and must also not depend on any feature of any programming language so that the calling should be easily possible from any language. There these C# specific annotations are of no use since you don't get any additional safety and you just have to write more code which at the end gains you nothing. In general, i can understand the objections against adding these syntax annotations at the call site. When i started programming in C#, coming from a C++ background, i found writing these additional annotations rendundant and annoying and a complete waste of time. But when you are developing in a team where you often have to read the code written by other team members and they have to read your code, then you really begin to see the merits. But it is also a good reminder for yourself when you have to look or modify code you have written a long time ago. A colleague of mine also mentioned, that you can see "a simulation" of the ref/out annotations using pointers / references as an idiom nowadays in a lot of C++ code too. If a function argument will be modified in some way you use a pointer and const references when it won't: e.g. if you have a function / method: void transmogrify(const MogrifyType& a, const MogrifyType& b, MogrifyType* out) you would call it: transmogrify(a, b, &c); Using this convention throughout the code you can see at the call site that a and b are input parameters and c will be modified. For example the render system "pbrt" ( http://pbrt.org/ ) uses this as an convention in their C++ code and it is explicitly mentioned in chapter 1.5.1 "pointer or reference" in the introduction.
Sep 11 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
 Actually the darndest thing is that C# has retired the syntax 
 in 5.0 (it used to be required up until 4.0). Apparently users 
 complained it was too unsightly.

 Andrei

Wh-huh?? Reference please. I have sought out info about C# 5 multiple times and I never heard that. Anyway I don't mind if ref is not required, but it ticks me off that it is not *allowed*. Even in C++ I can use "OUT" and "IN OUT" at both the definition and call sites (I may as well, since Windows header files #define them already). The compiler doesn't verify it but I find it useful to make the code self-documenting. Some have said that "well if the the compiler doesn't enforce it then it's pointless, you won't be able to tell if a call site without 'ref' is passed by ref". But no, it's not pointless, because (1) if you see a call site WITH 'ref' then clearly it is passed by reference, (2) I would use 'ref' consistently in my own code so that when I look back at my code a year later, the absence of 'ref' is a clear indication that it is an input parameter, and (3) if the compiler offered the option to issue a warning when 'ref' is absent, statement (2) would be true 100% of the time, in my code, instead of just 98%. Most of the code I look at is my own so that's my primary motive for wanting 'ref'. Yes, if 'ref' were allowed, some people would not use it; so when looking at a new code base I'd have no guarantee that a parameter NOT marked ref is passed by value. But at least (1) still applies.
Sep 11 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
 void func (ref int[], int)

 If ref/out were required at the call site, this destroys UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.


 Why? UFCS means uniform function call syntax.

by reference: struct Foo { int x = 0; void f() { x++; } } void obvious() { Foo foo; foo.f(); // x is passed to f() by reference } Perhaps your argument makes sense for classes, but not for structs. In any case the syntax (ref foo).f() would require extra work for Walter so I would not propose it. What I might propose instead is that, if the user requests (via command-line argument such as '-callSiteRef') that a warning be issued for arguments passed without 'ref' at the call site, then a situation like this should prompt a warning. class Bar { int b; } void changeBar(ref Bar b) { b = new Bar(); } void warning() { Bar bar = new Bar(); bar.b = 10; bar.changeBar(); // Warning: 'bar' is implicitly passed by reference. To eliminate this warning, use 'changeBar(ref bar)' instead or do not compile with '-callSiteRef' } Again, this problem only applies to classes, since it is understood that structs are normally passed by reference.
 Also for 'const ref' parameters, callsite ref should not be 
 necessary.

'non-obvious' as well when there is no callsite ref.

If you're referring to the fact that it's easy to have a D pointer to a stack variable outlive the variable... I don't think that this 'flaw' (I think of it as a flaw, others may think of it as a feature) is a good enough reason to say 'call site ref should be required for const ref parameters'.
 for value types, it is arguably important.

This is not necessarily a valid conclusion. Popularity does not imply importance.

I think 'ref' is a popular idea because people have used it in C# and liked it. I didn't start putting 'IN OUT' and 'OUT' in my C++ code until C# taught me the value of documenting it at the call site.
 Generally speaking, if a parameter being
 ref/out is surprising, there is something wrong with the 
 design.  (There
 are times it is non-obvious in otherwise good code, this 
 seems uncommon.)



I often want to 'scan' code to see what it does. Especially for debugging, I want to see where the side-effects are QUICKLY. Guessing which parameters are 'ref' requires me to analyze the code in my head. Even if I myself wrote the code, it can be time consuming. That's why I would prefer to explicitly mark possible side effects with 'ref' (of course, when passing a class to a function, the class members may be modified when the reference to the class was passed by value. But it is far easier to keep track of which classes are mutable than to keep track of which parameters of which functions are 'ref', because functions far outnumber classes.)
 IMHO it is better left to the future D editor.

That's probably a long way off.
Sep 11 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 11 Sep 2012 13:36:23 +0200
S=F6nke Ludwig <sludwig outerproduct.org> wrote:

 Am 08.09.2012 20:17, schrieb Timon Gehr:
 Agh, sent a private mail again. I don't seem to be the only one
 though. Has there been a thunderbird UI change?
=20

They exchanged the order of the "Reply" and "Smart reply" buttons in TB 15. This also hit me several times, very annoying. You can switch them back using "Customize" in the context menu though. =20

Mozilla's constantly screwing around with their UIs. You're lucky in this case: Usually you can't revert their UI shenanigans without just simply downgrading or going through the bother of writing a whole plug-in.
Sep 11 2012
prev sibling next sibling parent "Manuel" <manuel d.org> writes:
On Tuesday, 11 September 2012 at 17:57:17 UTC, David Piepgrass 
wrote:
 void func (ref int[], int)

 If ref/out were required at the call site, this destroys 
 UFCS.

 int[] array;
 array.func(0); // error, ref not specified by caller

For UFCS, ref should be implied.


 Why? UFCS means uniform function call syntax.

passed by reference: struct Foo { int x = 0; void f() { x++; } } void obvious() { Foo foo; foo.f(); // x is passed to f() by reference } Perhaps your argument makes sense for classes, but not for structs. In any case the syntax (ref foo).f() would require extra work for Walter so I would not propose it. What I might propose instead is that, if the user requests (via command-line argument such as '-callSiteRef') that a warning be issued for arguments passed without 'ref' at the call site, then a situation like this should prompt a warning. class Bar { int b; } void changeBar(ref Bar b) { b = new Bar(); } void warning() { Bar bar = new Bar(); bar.b = 10; bar.changeBar(); // Warning: 'bar' is implicitly passed by reference. To eliminate this warning, use 'changeBar(ref bar)' instead or do not compile with '-callSiteRef' } Again, this problem only applies to classes, since it is understood that structs are normally passed by reference.
 Also for 'const ref' parameters, callsite ref should not be 
 necessary.

'non-obvious' as well when there is no callsite ref.

If you're referring to the fact that it's easy to have a D pointer to a stack variable outlive the variable... I don't think that this 'flaw' (I think of it as a flaw, others may think of it as a feature) is a good enough reason to say 'call site ref should be required for const ref parameters'.
 for value types, it is arguably important.

This is not necessarily a valid conclusion. Popularity does not imply importance.

I think 'ref' is a popular idea because people have used it in C# and liked it. I didn't start putting 'IN OUT' and 'OUT' in my C++ code until C# taught me the value of documenting it at the call site.

Like i have written above, when switching from C++ to C# i found it at first annoying but now i wished i would have it in C++ too. One possibility to simulate this in C++ is like the pbrt people have done it with const references and pointers (look at my post above for further details).
 Generally speaking, if a parameter being
 ref/out is surprising, there is something wrong with the 
 design.  (There
 are times it is non-obvious in otherwise good code, this 
 seems uncommon.)



I often want to 'scan' code to see what it does. Especially for debugging, I want to see where the side-effects are QUICKLY. Guessing which parameters are 'ref' requires me to analyze the code in my head. Even if I myself wrote the code, it can be time consuming. That's why I would prefer to explicitly mark possible side effects with 'ref' (of course, when passing a class to a function, the class members may be modified when the reference to the class was passed by value. But it is far easier to keep track of which classes are mutable than to keep track of which parameters of which functions are 'ref', because functions far outnumber classes.)

+1 It's not only that you yourself want to 'scan' through your code and QUICKLY see where parameters in function calls are modified but others might have to read your code aswell for code reviewing without browsing in the hopefully existing documentation for every single function / method. People in companies normally are not programming in isolation but are working in a team and teams often change.
 IMHO it is better left to the future D editor.

That's probably a long way off.

Yes. Looking at the current overall state of the d toolchain that might be a very long way off. And even then, inmho, it would be a not so good solution because it would be a feature which would tie users who want this feature to a specific editor / ide.
Sep 11 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 11 September 2012 at 16:49:45 UTC, Manuel wrote:
 On Tuesday, 11 September 2012 at 08:10:21 UTC, Andrei 
 Alexandrescu wrote:
 On 9/11/12 1:28 AM, Manuel wrote:
 Citation? I'm using C# 5.0 with Visual Studios 2012 on 
 Windows 8 right
 now and ref/out are still required at the call sight of 
 functions.

I have Visual Studio 2012 RC and can confirm, that ref and out are still required even with C# 5.0 (but maybe there is some compiler switch to disable this ??)

Erik Meijer didn't get back to me yet about that with a link, but he did mention that the relaxation was only allowed for COM calls. Andrei

OK, i see. For COM calls that might make sense, since binary COM modules are mostly written in C/C++ and must also not depend on any feature of any programming language so that the calling should be easily possible from any language. There these C# specific annotations are of no use since you don't get any additional safety and you just have to write more code which at the end gains you nothing. In general, i can understand the objections against adding these syntax annotations at the call site. When i started programming in C#, coming from a C++ background, i found writing these additional annotations rendundant and annoying and a complete waste of time.

Having used Turbo Pascal before I was doing C, I never understood why so many developers cry for this at the call site. I never had any problem with "var" parameters on Turbo Pascal (or other languages from Wirth), nor with references in C++. As I am not language religious, I just use them the way the language provides them. -- Paulo
Sep 12 2012
prev sibling next sibling parent "Minas" <minas_mina1990 hotmail.co.uk> writes:
I disagree that it would be useful.
In C# it is useful because pointers that used a lot less than in 
D.

Consider this:

void f(ref int x)
{
...
}

...
int x = 5;
f(ref x); // good, passed by reference
...


But:
void g(int* p)
{
...
}

...
int x = 5;
g(&x); // passed by reference as well, but it is not explicit 
like before. You don't even know if it's a const pointer if you 
don't read the function's signature.
...

So someone has this cool idea which is also present in some other 
programming language and thinks it would be nice to add it to D. 
That's not how it works. Then come the problem with things not 
properly designed etc etc.

Anyway, who needs to see f(ref x) when you can put your mouse 
above the function call and see its declaration? All modern IDEs 
support that - and I don't think C# guys use plain text editors.
Sep 12 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Minas:

 g(&x); // passed by reference as well, but it is not explicit 
 like before. You don't even know if it's a const pointer if you 
 don't read the function's signature.

The presence of "&" at call site acts exactly like the "ref" at the call site. In both cases you don't know if it's const/immutable. Bye, bearophile
Sep 12 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Minas wrote:
 Anyway, who needs to see f(ref x) when you can put your mouse 
 above the function call and see its declaration? All modern 
 IDEs support that - and I don't think C# guys use plain text 
 editors.

People debugging large bodies of code should not be required to hover the mouse over each and every function parameter for a second to properly understand structure. People using non-tooltip text editors have an even harder time. I think you're missing the point. This code: int* x; foo(&x); at least tells you there's a _potential_ x is being manipulated rather than just used. We don't need full insight into what's going on, just a helpful hint which narrows the potential culprits when debugging. If fact, it would nice if even reference types where required to follow similar "is modified in function" semantics, and I have ideas about that, but I'm not going there right now...
Sep 12 2012
prev sibling next sibling parent "Manuel" <manuel d.org> writes:
On Wednesday, 12 September 2012 at 07:36:24 UTC, Paulo Pinto 
wrote:
 On Tuesday, 11 September 2012 at 16:49:45 UTC, Manuel wrote:
 On Tuesday, 11 September 2012 at 08:10:21 UTC, Andrei 
 Alexandrescu wrote:
 On 9/11/12 1:28 AM, Manuel wrote:
 Citation? I'm using C# 5.0 with Visual Studios 2012 on 
 Windows 8 right
 now and ref/out are still required at the call sight of 
 functions.

I have Visual Studio 2012 RC and can confirm, that ref and out are still required even with C# 5.0 (but maybe there is some compiler switch to disable this ??)

Erik Meijer didn't get back to me yet about that with a link, but he did mention that the relaxation was only allowed for COM calls. Andrei

OK, i see. For COM calls that might make sense, since binary COM modules are mostly written in C/C++ and must also not depend on any feature of any programming language so that the calling should be easily possible from any language. There these C# specific annotations are of no use since you don't get any additional safety and you just have to write more code which at the end gains you nothing. In general, i can understand the objections against adding these syntax annotations at the call site. When i started programming in C#, coming from a C++ background, i found writing these additional annotations rendundant and annoying and a complete waste of time.

Having used Turbo Pascal before I was doing C, I never understood why so many developers cry for this at the call site. I never had any problem with "var" parameters on Turbo Pascal (or other languages from Wirth), nor with references in C++. As I am not language religious, I just use them the way the language provides them. -- Paulo

You just have cut away the last part of the history of my life and completely changed my statement to the reverse ;-) That last part was were i was getting my enlightenment and started to embrace additional annotations at the call site. From there i never looked back and lived a happier and more glorious life with a lot of profit and lot less errors ;-) Kevin just put this up for discussion because he realized while porting code from C# to D that he got wrong function calls on overloaded functions because of missing call site parameter annotations and just asked about the general opinion in the D community to add these to the language. I and a lot of the other participants in this thread just asserted that it would be a nice addition to D. That does not mean, we were "crying" for these or that we are "language religious" or that without them we would have unsolvable problems and would forever quit programming in D and switch over to QuickBasic again. It was more just a survey about the general opinion in the community. And as an intermediate result (which is not even close to be representive), the majority of the participants of this thread would like to have these added to the language, some just don't care and some don't like the idea at all. From those who didn't like the idea the most heared counter-argument was more like: "I know my code, i have written it, so i know which method modifies which parameters. I don't need this it makes me do more work." Which in my opinion is a bit shortsighted since in commercial development or in general when you work in a team you don't program in isolation and you have to often use third-party-frameworks were you don't have written every method by yourself. That's why the Microsoft language designer added this to C# and you even find this in a simulated way in C++ realised with references and pointers. The only valid counter-arguments brought up so far, were possible breakage of code (when it would be enforced) and maybe UCFS.
 As I am not language religious, I just use them the way the
 language provides them.

The good thing here in the open source world is that we are not bound to the decision of a big committee. It's not "you'll eat what's put in front of you". If a bigger part of the D community would like to have these annotations added to the language, at least as an optional feature, then that might persuade our "benevolent dictators" (just joking - you are great!) Walther and Andrei to add them or we could just make a fork of the language and add them ourselves (more joking - no, just skip this last part - it's late) :-) There might be other problems, maybe with the compiler internals or breakage of parts of the language. These were severe. But i think only Walther and Andrei might tell. If these wouldn't exist it would at least be possible, how David proposed it in his post, to make them optional. At the end that won't stop me or any other poster from programming in D. It would just really be nice to see this little extra of parameter checking at least optionally in D since with all the other safeness-features like safeD, contracts, etc. it would be a good addition to the language.
Sep 12 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
In D:

class A { // or struct
     A(ref int host) : _host(&host) { }
private:
     int* _host;
}

Since when do we have initialization lists in D? ;)

at topic: +1
Sep 13 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 13 September 2012 at 10:34:00 UTC, Andrei 
Alexandrescu wrote:
 The thing is, however, that in this matter reasonable people 
 may disagree.

Sounds exactly like the C# lambda syntax situation.
Sep 13 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
 I don't think there would be problems with allowing ref/out 
 optionally at the call site. The thing is, however, that in 
 this matter reasonable people may disagree.
 I'd be unable to identify any pattern in engineers choosing one 
 preference over the other.

Maybe C++ fans prefer pointers or implicit ref, C# fans prefer call-site ref?
 Now that the subject has been broken, we do have good evidence 
 of a pattern that generates significant and difficult bugs: 
 escaping the address of a reference. In C++:

 struct A {
     A(int& host) : host_(host) {}
 private:
     int& host_;
 };

 In D:

 class A { // or struct
     A(ref int host) : _host(&host) {}
 private:
     int* _host;
 }

 A solution we use for C++ is to require escaped addresses to be 
 always passed as pointers or smart pointers.

 Walter and I have discussed this for quite a while. We have 
 recently decided to disallow, at least in SafeD, escaping the 
 address of a ref parameter. In the beginning we'll be overly 
 conservative by disallowing taking the address of a ref 
 altogether. I'll write a DIP on that soon.

Err, wouldn't that break a lot of stuff, a lot of which is actually safe code? void a(ref int x) { b(&x); } void b(int* x) { if(x != null) (*x)++; } Escaping the addresses of stack variables, not just ref parameters, is a general problem in "safe" D. Do you have any ideas about that?
Sep 13 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 13, 2012 12:34:34 Andrei Alexandrescu wrote:
 I don't think there would be problems with allowing ref/out optionally
 at the call site. The thing is, however, that in this matter reasonable
 people may disagree.

I really think that optionally allowing ref and out at the call site is more damaging than beneficial. _Requiring_ it could be beneficial, since then you know that the arguments are being taken by ref, but if it's optional, it gives you a false sense of security and can be misleading. Presumabyl, any time that ref or out is used at a call site, presumably the compiler would check that it really was passed by ref our out, which would be of some benefit, but it would mean _nothing_ if ref or out wasn't used, since it could be an argument being passed by ref but which wasn't marked or an argument which wasn't passed by ref at all. So, if you have code where ref and out is used at the call site semi-religiously, then it'll become very easy to falsely think that the lack of them means that ref or out _isn't_ being used when it really is, misleading people about what the code is doing. So, if it wasn't going to break so much code, I'd see some argument for changing things so that ref and out were required at the call site, but I think that _allowing_ them but not requiring them would actually be detrimental. - Jonathan M Davis
Sep 13 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
On Thursday, 13 September 2012 at 15:01:28 UTC, Andrei 
Alexandrescu wrote:
 On 9/13/12 10:53 AM, David Piepgrass wrote:
 Walter and I have discussed this for quite a while. We have 
 recently
 decided to disallow, at least in SafeD, escaping the address 
 of a ref
 parameter. In the beginning we'll be overly conservative by
 disallowing taking the address of a ref altogether. I'll 
 write a DIP
 on that soon.

Err, wouldn't that break a lot of stuff, a lot of which is actually safe code? void a(ref int x) { b(&x); } void b(int* x) { if(x != null) (*x)++; }

Yes. Disallowing taking the address of a local is conservative and would disallow a number of valid programs. Arguably, such programs are in poor style anyway. A good program takes pointers only if it needs to keep them around; if all that's needed is to use the parameter transitorily or pass it down, ref is best.

Another common reason to use a pointer (instead of ref) is if it's optional (nullable). If the parameter is ref then the caller must go to the trouble of creating a variable. However, this could be solved with a feature like the following: int* find(string searchString, out int index) { ... } // _ means "don't care", assuming no variable "_" is defined void caller() { find("foo", out _); } In fact this is arguably better for 'out' variables since the callee (find) no longer has to check whether 'index' is null before assigning it. However this doesn't totally solve the problem for 'ref' parameters, since such parameters are both output and input parameters and the programmer may want 'null' to have some special meaning as an input.
 Escaping the addresses of stack variables, not just ref 
 parameters, is a
 general problem in "safe" D. Do you have any ideas about that?


int* unsafe1() { int x = 1; return unsafe2(&x); } int* unsafe2(int* x) { return x; } int unsafe3() { int y = 7; *unsafe1() = 8; return y; } enum gaff = unsafe3(); // ICE, no line number given
 Same thing. By and large safe programs will need to make more 
 use of the garbage collector than others. It's the way things 
 work; stack allocation can be made safer if we add typed 
 regions, but that's a very significant escalation of 
 complication. There is no simple solution to this today.

Same thing meaning that you'd propose disallowing taking the address of a stack variable in SafeD? (I guess this would include escaping 'this' within a struct.)
Sep 13 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
 I really think that optionally allowing ref and out at the call 
 site is more
 damaging than beneficial. _Requiring_ it could be beneficial, 
 since then you
 know that the arguments are being taken by ref, but if it's 
 optional, it gives
 you a false sense of security and can be misleading.

It gives *who* a false sense of security? If it's optional then I *know* lack of ref/out doesn't imply that the parameter won't change. Only people who don't know the rules would have this false sense of security. I think it would be nice to have it required, but it's very bad to break everyone's code. It could only be reasonably enforced with a compiler switch--or, wait, come to think of it, a pragma would probably be better way to introduce language changes like this: module foo; pragma(callSiteRef); // and would it make sense to offer an alternative to -property too? pragma(property); Now you can tell whether a program uses ref/out religiously or not.
Sep 13 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 13 September 2012 at 16:29:19 UTC, Andrei 
Alexandrescu wrote:
 It gives *who* a false sense of security?

It's "whom". Andrei P.S. All of my life I've been waiting for this moment!!!

LOL
Sep 13 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 13, 2012, at 7:21 AM, Andrei Alexandrescu =
<SeeWebsiteForEmail erdani.org> wrote:
=20
 One question Walter and I thought about a lot was whether we should =

safe code. We decided to go for the latter in order to avoid breakage = of existing code. Thoughts? I love the idea. However, this could complicate working with C APIs, = particularly regarding structs which are often passed by reference as a = matter of course. For example: struct some_c_struct {} void fn(ref some_c_struct s) { some_c_func(&s); } I guess the only way to know if this will turn out to be a real issue is = to give it a try though.=
Sep 13 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 13, 2012 17:47:45 David Piepgrass wrote:
 It gives *who* a false sense of security? If it's optional then I
 *know* lack of ref/out doesn't imply that the parameter won't
 change. Only people who don't know the rules would have this
 false sense of security.

More like anyone reading the code but especially when someone _other_ than you is reading your code. I'd fully expect that there would be quite a few programmers who would assume that the lack of ref at the call site would mean that it's not passed by ref when the code uses ref and out at the call site all over the place. And because the lack of ref or out at the call site means nothing, you're always going to have to either know whether the function takes its arguments by ref or not, or you're going to have to look up the function anyway. And if that's the case, actually using ref or out at the call site buys you almost nothing. - Jonathan M Davis
Sep 13 2012
prev sibling next sibling parent "Manuel" <manuel d.org> writes:
On Thursday, 13 September 2012 at 15:18:06 UTC, Jonathan M Davis 
wrote:
 On Thursday, September 13, 2012 12:34:34 Andrei Alexandrescu 
 wrote:
 I don't think there would be problems with allowing ref/out 
 optionally
 at the call site. The thing is, however, that in this matter 
 reasonable
 people may disagree.

I really think that optionally allowing ref and out at the call site is more damaging than beneficial. _Requiring_ it could be beneficial, since then you know that the arguments are being taken by ref, but if it's optional, it gives you a false sense of security and can be misleading. Presumabyl, any time that ref or out is used at a call site, presumably the compiler would check that it really was passed by ref our out, which would be of some benefit, but it would mean _nothing_ if ref or out wasn't used, since it could be an argument being passed by ref but which wasn't marked or an argument which wasn't passed by ref at all. So, if you have code where ref and out is used at the call site semi-religiously, then it'll become very easy to falsely think that the lack of them means that ref or out _isn't_ being used when it really is, misleading people about what the code is doing. So, if it wasn't going to break so much code, I'd see some argument for changing things so that ref and out were required at the call site, but I think that _allowing_ them but not requiring them would actually be detrimental. - Jonathan M Davis

I see your point here but, as David already argued in his post, it would only be detrimental if people would not realise that these annotations are not obligatory. If that is clearly stated, i don't see so much of a problem here. E.g. if we have a function / method call: transmogrify(myValueType1, myValueType2, myValueType3); Right now we don't know whether any of these values is going to be modified or not. And with _optional_ annotations allowed we couldn't say neither. That situation is not worse than the situation we have now. Things would only be bad if people would wrongly think that call site annotations are obligatory. But if we would see the function call: transmogrify(myValueType1, myValueType2, out myValueType3); in some unknown piece of code we could at least surely know that myValueType3 is going to be modified. We couldn't say anything about myValueType1 or myValueType2 with optional annotations. The other parameters could or couldn't be modified. But we have at least a bit more context / information (e.g. that the function has side-effects). Normally functions / methods have better names so we would have even more context. If it would be possible to allow call site annotations for the people who want to use them as an additional documentation / safety feature and maybe make the compiler emit warnings (through an optional compiler switch) if they are omitted or just allow them, as long as it's clear that they are optional, i don't see any problem with it.
Sep 13 2012
prev sibling next sibling parent "Manuel" <manuel d.org> writes:
On Thursday, 13 September 2012 at 10:34:00 UTC, Andrei 
Alexandrescu wrote:
 On 9/13/12 1:02 AM, Manuel wrote:
 If a bigger part of the D community would like to have these 
 annotations
 added to the language, at least as an optional feature, then 
 that might
 persuade our "benevolent dictators" (just joking - you are 
 great!)
 Walther and Andrei to add them or we could just make a fork of 
 the
 language and add them ourselves (more joking - no, just skip 
 this last
 part - it's late) :-)

 There might be other problems, maybe with the compiler 
 internals or
 breakage of parts of the language. These were severe. But i 
 think only
 Walther and Andrei might tell. If these wouldn't exist it 
 would at least
 be possible, how David proposed it in his post, to make them 
 optional.

I don't think there would be problems with allowing ref/out optionally at the call site. The thing is, however, that in this matter reasonable people may disagree. In C++, the equivalent argument (should we pass everything modifiable by pointer or not?) erupts every six months on internal fora at Facebook. No winning argument is made by either part. For example, it is often brought up that it's good to see "&" at the call site when debugging some urgent matter at 3am. Yet there are other people who are just as apt at debugging urgent matters at 3am, and the absence of "&" doesn't seem to be a handicap for them at all. I'd be unable to identify any pattern in engineers choosing one preference over the other. As a consequence, our code has a mix of pass-by-pointer and pass-by-reference-to-nonconst, all engineers manage either style just as well, and we've never been able to find any evidence pointing one way or another. Now that the subject has been broken,

Thanks Andrei for sharing your experience with this matter in your working environment (after all, it's "Facebook" and not "John Nobody and Sons Inc."). To be honest, i and i think even Kevin, who started this thread, didn't expect such lively reactions. But Kevins thread seems to struck a nerve. And i think you made a very important point here. Whether someone would like to have this feature in the language or not is, despite all technical reasons / merits, also a psychological thing or a matter of taste.
 people who are just as apt at debugging urgent matters at 3am, 
 and the absence of "&" doesn't seem to be a handicap for them 
 at all

I think every competent programmer can handle both cases well (even at 3am). It's more, and here you are right, where you want to spend your time. Do you want to spend your time looking up all the function/method signatures you don't know / remember or spend it writing endless call site annotations. Do you want to spend your time debugging strange side-effects or want to write annoying annotations just to please the compiler. At the end, at 3am, it might result in the same level of productivity. (1) transmogrify(MyValueType1, MyValueType2, MyValueType3); The disadvantage here is, that if you don't know / have written the function you don't know whether if and which parameters might be modified. So you have to look the function signature up, no other choice here. There is no way for a quick read over the code. The advantage is that you save yourself writing endless annoying anotations, safe some typing and have less noise. (2) transmogrify(MyValueType1, MyValueType2, out MyValueType3); The disadvantage here is more typing, more noise. The advantage is that you as a programmer are forced to confirm that you know that this call will modify the value type and you want it this way, so nothing happens accidently. It's basically a double-check. You say i know this function will modify things and i want it that way. It gives people who read / review the code also more informations at a quick glance so they don't have too look things up constantly. Whether you want something double checked might really depend on your personality (maybe i am more the anxious type and you are the bungee jumper type ;-) ). So i think it basically boils down to this. I think it would fit do D because of the safety concept inside the language (as it is similar to contracts). Since you don't seem to be overzealous regarding this (if i interpreted your confession rightly ;-) ) then it might be the best to leave all as it is. I would like to have heared more arguments like: it breaks down certain language constructs, there are problems with templates or UCFS, or maybe from Walther that it makes too much work on the compiler side which could be spend better for other things or such. But as i have written i haved lived without call site annotations in D and can live on without them. And honestly, i even think there are also more important things to be adressed in D (the classic one like bugs, toolchain, etc.). So maybe the best contribution so far came from Paulo Pinto. To take things as they are and concentrate on more important things. But it's at least a good thing that we discussed this ;-)
 we do have good evidence of a pattern that generates 
 significant and difficult bugs: escaping the address of a 
 reference. In C++:

 struct A {
     A(int& host) : host_(host) {}
 private:
     int& host_;
 };

 In D:

 class A { // or struct
     A(ref int host) : _host(&host) {}
 private:
     int* _host;
 }

 A solution we use for C++ is to require escaped addresses to be 
 always passed as pointers or smart pointers.

 Walter and I have discussed this for quite a while. We have 
 recently decided to disallow, at least in SafeD, escaping the 
 address of a ref parameter. In the beginning we'll be overly 
 conservative by disallowing taking the address of a ref 
 altogether. I'll write a DIP on that soon.


 Andrei

Sep 13 2012
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
Couldn't this easily be supported by an IDE by coloured function 
arguments based on their type? Then the information is clearly 
visible without cluttering the code.
Sep 13 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote:
 Couldn't this easily be supported by an IDE by coloured 
 function arguments based on their type? Then the information is 
 clearly visible without cluttering the code.

no because... wait... that... that could work.
Sep 13 2012
prev sibling next sibling parent "Manuel" <manuel d.org> writes:
On Friday, 14 September 2012 at 06:55:00 UTC, F i L wrote:
 On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote:
 Couldn't this easily be supported by an IDE by coloured 
 function arguments based on their type? Then the information 
 is clearly visible without cluttering the code.

no because... wait... that... that could work.

Ok. Then ... who is writing this IDE ?
Sep 14 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Friday, 14 September 2012 at 22:20:16 UTC, Manuel wrote:
 On Friday, 14 September 2012 at 06:55:00 UTC, F i L wrote:
 On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote:
 Couldn't this easily be supported by an IDE by coloured 
 function arguments based on their type? Then the information 
 is clearly visible without cluttering the code.

no because... wait... that... that could work.

Ok. Then ... who is writing this IDE ?

I'm just saying it's a solution that doesn't require adding a breaking feature to D. I know MonoDevelop has the ability to color user-types and such, maybe eventually Alex will be able to add such a feature. If the compiler developers can't or won't add 'foo(ref x)' semantics to the compiler, then this is really the only option left available that gives the same level of insight to developers that C# does.
Sep 14 2012
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
It'd be great if the guy doing Visual D could give it a try. We 
could also resolve the property vs function issue in a similar 
manner to avoid the need to enforce unnecessary brackets 
everywhere. It would seem like a more practical approach than 
breaking all D2 code that actually addresses the legitimate issue.
Sep 14 2012
prev sibling next sibling parent Ziad Hatahet <hatahet gmail.com> writes:
--047d7bdc876e7159d704ca008ed1
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr <timon.gehr gmx.ch> wrote:

 Yes, Go uses explicit pointer types.
 Regarding Rust, you are wrong.
 I have built the latest Rust compiler.

 import io;

 fn modify(&a:int){
     a = 2;
 }
 fn swap<T>(&a:T,&b:T){
    let tmp<-a;
    a<-b;
    b<-tmp;
 }

T)`. So your modify function becomes: `fn modify(a: &mut int)`, and gets called as `modify(&mut a)`. Your swap function becomes `fn swap<T>(a: &mut T, b: &mut T)` and gets called as `swap(&mut a, &mut b)`. So effectively, Rust also opted for explicit ref at the call site. -- Ziad --047d7bdc876e7159d704ca008ed1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><br></div> Yes, Go uses explicit pointer types.<br> Regarding Rust, you are wrong.<br> I have built the latest Rust compiler.<br> <br> import io;<br> <br> fn modify(&amp;a:int){<br> =A0 =A0 a =3D 2;<br> }<br> fn swap&lt;T&gt;(&amp;a:T,&amp;b:T){<br> =A0 =A0let tmp&lt;-a;<br> =A0 =A0a&lt;-b;<br> =A0 =A0b&lt;-tmp;<br> }<br> <br> </blockquote></div><div><br></div>The `fn foo(&amp;a: T)` syntax is being d= eprecated in favor of `fn foo(a: &amp;mut T)`.<div><br></div><div>So your m= odify function becomes: `fn modify(a: &amp;mut int)`, and gets called as `m= odify(&amp;mut a)`.</div> <div><br></div><div>Your swap function becomes `fn swap&lt;T&gt;(a: &amp;mu= t T, b: &amp;mut T)` and gets called as `swap(&amp;mut a, &amp;mut b)`.<div=

</div><div><br clear=3D"all">--<br>Ziad<br></div> </div> </div> --047d7bdc876e7159d704ca008ed1--
Sep 18 2012
prev sibling parent "Kevin McTaggart" <kevin.mctaggart drdc-rddc.gc.ca> writes:
I'm amazed and very pleased at the discussion that this has 
generated.  I think it would be great if ref and out required for 
function calls in D3.  As others have mentioned, it would greatly 
assist with code readability.

On Friday, 7 September 2012 at 11:33:41 UTC, Kevin McTaggart 
wrote:
 I've been looking at migrating a reasonably large ship motion 
 library (tens of thousands of lines) from C# to D.  I've become 
 quite enthusiastic about D, and most of my problems have been 
 relatively minor (e.g., inconsistent bugs with 
 std.container.Array, would like orange serialization to give me 
 an error telling me I didn't register a class before calling 
 serialize).  I suggest that the language require ref and out 
 when calling functions, as C# requires.  This would make code 
 easier to understand, and would also eliminate the problem I 
 had when the wrong function from the following choices was 
 mistakenly called:

 parseLineInts(string text, int positionStart, out int j0, out 
 int j1)

 parseLineInts(string text, out int j0, out int j1, out int j2)

 I note that the second function calls another function as 
 follows:
 int positionStart = 1;
 parseLineInts(text, positionStart, j0, j1, j2);

 I look forward to seeing feedback from D experts.  This is the 
 only significant change that I could think of recommending for 
 the language.

Sep 19 2012