Re: Would like to see ref and out required for function calls
On 09/18/2012 11:26 PM, Ziad Hatahet wrote:
On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@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 swapT(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 swapT(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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr timon.g...@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 swapT(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 swapT(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
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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 ?
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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?
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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?
Btw just a simple illustrative example:
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.)
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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!!!
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
On Sep 13, 2012, at 7:21 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
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?
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
+1
Why? UFCS means uniform function call syntax.
It is already understood that the thing left of '.' may be 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.
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.
Re: Would like to see ref and out required for function calls
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).
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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...
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
+1
Why? UFCS means uniform function call syntax.
It is already understood that the thing left of '.' may be 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.
The callee might escape a pointer to the argument. Which is
'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.
Re: Would like to see ref and out required for function calls
On Tue, 11 Sep 2012 13:36:23 +0200 Sönke Ludwig slud...@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? 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. 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.
Re: Would like to see ref and out required for function calls
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.
+1
Why? UFCS means uniform function call syntax.
It is already understood that the thing left of '.' may be
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.
The callee might escape a pointer to the argument. Which is
'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.
Re: Would like to see ref and out required for function calls
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 swapT(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.
Re: Would like to see ref and out required for function calls
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 ??)
Re: Would like to see ref and out required for function calls
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 Such feature can be implemented as optional in D2 with compiler switch to enforce explicit ref and out syntax.
Re: Would like to see ref and out required for function calls
On 11-09-2012 06:21, zerg wrote: 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 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 a...@lycus.org http://lycus.org
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
On Fri, 07 Sep 2012 13:34:02 +0200 Kevin McTaggart kevin.mctagg...@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 :(
Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
On 9/7/12, Andrei Alexandrescu seewebsiteforem...@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?
Re: Would like to see ref and out required for function calls
On 9/7/12 4:55 PM, Andrej Mitrovic wrote: On 9/7/12, Andrei Alexandrescuseewebsiteforem...@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
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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?
Re: Would like to see ref and out required for function calls
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?
Re: Would like to see ref and out required for function calls
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.
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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
Re: Would like to see ref and out required for function calls
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
