digitalmars.D - Idea: Use out/inout when _calling_ functions as well
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> May 14 2005
- Vathix <vathix dprogramming.com> May 14 2005
- "Unknown W. Brackets" <unknown simplemachines.org> May 14 2005
- Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> May 17 2005
- Hasan Aljudy <hasan.aljudy gmail.com> May 17 2005
- Piotr Fusik <Piotr_member pathlink.com> May 18 2005
- Hasan Aljudy <hasan.aljudy gmail.com> May 18 2005
- "Ben Hinkle" <ben.hinkle gmail.com> May 14 2005
Was skimming through some C# source today, and I noticed something like this: SomeClass c; func(5, 10, out c); I remember someone saying that out and inout are great, but if you're not familiar with the code, you may not know which parameters are going to be modified by the function. At least in C++ you have to use the address-of operator, so that's usually a clue that something's going to happen to it. But in D, there is no indication as to which parameters are in, out, or inout, unless you look at the function declaration. I think it'd be a good idea to enforce the use of out and inout on parameters which are passed as such. It serves to self-document the code and it makes it explicit that something is going to happen to the parameter.
May 14 2005
I think it'd be a good idea to enforce the use of out and inout on parameters which are passed as such. It serves to self-document the code and it makes it explicit that something is going to happen to the parameter.
I like it. I think I proposed this before. Maybe at least make it optional: if specified, it must be correct.
May 14 2005
I like that idea. What else could "in", "inout" or, "out" mean there? Just like they're optional in the function declaration. -[Unknown]I think it'd be a good idea to enforce the use of out and inout on parameters which are passed as such. It serves to self-document the code and it makes it explicit that something is going to happen to the parameter.
I like it. I think I proposed this before. Maybe at least make it optional: if specified, it must be correct.
May 14 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vathix schrieb am Sat, 14 May 2005 18:17:04 -0400:I think it'd be a good idea to enforce the use of out and inout on parameters which are passed as such. It serves to self-document the code and it makes it explicit that something is going to happen to the parameter.
I like it. I think I proposed this before. Maybe at least make it optional: if specified, it must be correct.
The optional solution could be nice for catching logical bugs at compile time. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCiezl3w+/yD4P9tIRAiM/AKCzyCNNekEaM7zerhtNogoDV+CqCgCgvX0t G9eO11WEbHoJfOzpYcVRmsI= =+MiY -----END PGP SIGNATURE-----
May 17 2005
Vathix wrote:I think it'd be a good idea to enforce the use of out and inout on parameters which are passed as such. It serves to self-document the code and it makes it explicit that something is going to happen to the parameter.
I like it. I think I proposed this before. Maybe at least make it optional: if specified, it must be correct.
I don't mind, as long as it's optional.
May 17 2005
I don't mind, as long as it's optional.
No, it shouldn't be optional.
May 18 2005
Piotr Fusik wrote:I don't mind, as long as it's optional.
No, it shouldn't be optional.
To me, that just adds complexity that's not really necessary.
May 18 2005
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message news:d65hlc$1ket$1 digitaldaemon.com...Was skimming through some C# source today, and I noticed something like this: SomeClass c; func(5, 10, out c); I remember someone saying that out and inout are great, but if you're not familiar with the code, you may not know which parameters are going to be modified by the function. At least in C++ you have to use the address-of operator, so that's usually a clue that something's going to happen to it. But in D, there is no indication as to which parameters are in, out, or inout, unless you look at the function declaration. I think it'd be a good idea to enforce the use of out and inout on parameters which are passed as such. It serves to self-document the code and it makes it explicit that something is going to happen to the parameter.
'out' or 'inout' at the call site would also enable an overloadable opIndexMutable for expressions like func(5,10,out x["hello"]); where x is a user-defined type. Currently there is no way to use overloaded indexing as an lvalue. See the thread about opIndexMutable started by Kevin Bealer last month.
May 14 2005









"Unknown W. Brackets" <unknown simplemachines.org> 