digitalmars.D - `return const` parameters make `inout` obsolete
- Zach the Mystic (4/4) Mar 16 2015 char* fun(return const char* x);
- ketmar (2/7) Mar 16 2015 but why compiler has to rewrite return type? i never told it to do that!...
- Zach the Mystic (7/17) Mar 16 2015 It has to if you pass an immutable to x, which you're allowed to
- ketmar (4/21) Mar 16 2015 this is the question of consistency. if i wrote `char* fun()`, i want fu...
- Zach the Mystic (7/37) Mar 16 2015 I think it's just less cluttered than `inout`. The simple fact is
- ketmar (8/13) Mar 16 2015 having argument modifier that changes function return type is very=20
- Zach the Mystic (8/21) Mar 16 2015 I feel like you're reacting more to "Change" than to my actual
- ketmar (5/18) Mar 16 2015 your change includes both observation and syntax change. i don't want to...
- Idan Arye (3/7) Mar 16 2015 Is the `return` in the argument list a new feature? It doesn't
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (3/11) Mar 16 2015 It's been experimentally introduced by DIP25:
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (8/12) Mar 16 2015 That's a very interesting observation. I never liked the name
- Zach the Mystic (14/27) Mar 16 2015 `return` would work just as well for uniqueness.
- Nick Treleaven (2/6) Mar 17 2015 inout can be used for local variables too.
- Zach the Mystic (18/27) Mar 17 2015 Yeah that might be a use for it.
- ixid (4/11) Mar 17 2015 Why is this ability important? It feels like trying to distort
- Zach the Mystic (11/23) Mar 17 2015 I don't know for sure. I think the main point of `inout` is to
char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.
Mar 16 2015
On Mon, 16 Mar 2015 14:17:57 +0000, Zach the Mystic wrote:char* fun(return const char* x); =20 Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.but why compiler has to rewrite return type? i never told it to do that!=
Mar 16 2015
On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote:On Mon, 16 Mar 2015 14:17:57 +0000, Zach the Mystic wrote:It has to if you pass an immutable to x, which you're allowed to do. It only gives an error if you assign the result to a mutable variable. The point is that the signature still contains all the information it needs without `inout`. What old errors will fail to be reported and what new errors would it cause? I haven't been able to think of any.char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.but why compiler has to rewrite return type? i never told it to do that!
Mar 16 2015
On Mon, 16 Mar 2015 15:33:40 +0000, Zach the Mystic wrote:On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote:this is the question of consistency. if i wrote `char* fun()`, i want fun=20 to return `char*`, and i'm not expecting it to change in a slightest. i=20 don't like when compiler starts to change things on it's own.=On Mon, 16 Mar 2015 14:17:57 +0000, Zach the Mystic wrote:=20 It has to if you pass an immutable to x, which you're allowed to do. It only gives an error if you assign the result to a mutable variable. The point is that the signature still contains all the information it needs without `inout`. What old errors will fail to be reported and what new errors would it cause? I haven't been able to think of any.char* fun(return const char* x); =20 Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.but why compiler has to rewrite return type? i never told it to do that!
Mar 16 2015
On Monday, 16 March 2015 at 15:39:39 UTC, ketmar wrote:On Mon, 16 Mar 2015 15:33:40 +0000, Zach the Mystic wrote:I think it's just less cluttered than `inout`. The simple fact is that if you try to assign an immutable variable to a mutable reference, you will still get an error. I doubt it would take long for programmers to adjust to the new way of reading the signatures. They just see `return` sitting there in front of `const` and know how to handle the situation.On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote:this is the question of consistency. if i wrote `char* fun()`, i want fun to return `char*`, and i'm not expecting it to change in a slightest. i don't like when compiler starts to change things on it's own.On Mon, 16 Mar 2015 14:17:57 +0000, Zach the Mystic wrote:It has to if you pass an immutable to x, which you're allowed to do. It only gives an error if you assign the result to a mutable variable. The point is that the signature still contains all the information it needs without `inout`. What old errors will fail to be reported and what new errors would it cause? I haven't been able to think of any.char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.but why compiler has to rewrite return type? i never told it to do that!
Mar 16 2015
On Mon, 16 Mar 2015 15:54:19 +0000, Zach the Mystic wrote:I think it's just less cluttered than `inout`. The simple fact is that if you try to assign an immutable variable to a mutable reference, you will still get an error. I doubt it would take long for programmers to adjust to the new way of reading the signatures. They just see `return` sitting there in front of `const` and know how to handle the situation.having argument modifier that changes function return type is very=20 surprising regardless of how much people used to it. really, why should i=20 parse *arguments* to know the (explicitly specified!) *return* *type*?=20 it's ok with `auto`, it's ok with `inout`, but when i wrote `char *`, i=20 want `char *`. and then compiler decides that it knows better. ok,=20 compiler, you win, can you write the rest of the code for me? no? stupid=20 compiler!=
Mar 16 2015
On Monday, 16 March 2015 at 16:49:36 UTC, ketmar wrote:having argument modifier that changes function return type is very surprising regardless of how much people used to it. really, why should i parse *arguments* to know the (explicitly specified!) *return* *type*? it's ok with `auto`, it's ok with `inout`, but when i wrote `char *`, i want `char *`. and then compiler decides that it knows better. ok, compiler, you win, can you write the rest of the code for me? no? stupid compiler!I feel like you're reacting more to "Change" than to my actual point. `inout` wasn't invented because it looks good, but because it solves the DRY problem for different input types. `return` parameters also solve that problem, plus a few more, and with less DRY even than `inout`. I don't think either type if signature is that hard to read. It's just a matter of getting used to them.
Mar 16 2015
On Mon, 16 Mar 2015 18:46:10 +0000, Zach the Mystic wrote:On Monday, 16 March 2015 at 16:49:36 UTC, ketmar wrote:your change includes both observation and syntax change. i don't want to=20 separate them.having argument modifier that changes function return type is very surprising regardless of how much people used to it. really, why should i parse *arguments* to know the (explicitly specified!) *return* *type*? it's ok with `auto`, it's ok with `inout`, but when i wrote `char *`, i want `char *`. and then compiler decides that it knows better. ok, compiler, you win, can you write the rest of the code for me? no? stupid compiler!=20 I feel like you're reacting more to "Change" than to my actual point.It's just a matter of getting used to them.i can read Z80 machine code without disassembler. that doesn't means that=20 i like to do that.=
Mar 16 2015
On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote:char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.Is the `return` in the argument list a new feature? It doesn't compile in 2.066, and I don't see it in 2.067's changelog...
Mar 16 2015
On Monday, 16 March 2015 at 16:02:57 UTC, Idan Arye wrote:On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote:It's been experimentally introduced by DIP25: http://wiki.dlang.org/DIP25char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.Is the `return` in the argument list a new feature? It doesn't compile in 2.066, and I don't see it in 2.067's changelog...
Mar 16 2015
On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote:char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.That's a very interesting observation. I never liked the name `inout`, as it doesn't describe what it does. The only downside I see is that it's more magic, because nothing on the return type says its mutability is going to depend on an argument. I think Kenji also had additional plans for `inout`, related to uniqueness. There was a PR. Better ask him whether it's going to be compatible.
Mar 16 2015
On Monday, 16 March 2015 at 16:22:46 UTC, Marc Schütz wrote:On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote:`return` would work just as well for uniqueness. inout(T*) fun(inout(T*) x); -> T* fun(return const T* x); I don't think any information is being lost. My attitude is that unless you are losing information, the underlying logic won't be any harder to implement. I think that `return` parameters are a building block of `inout`, but more useful because they can be used separately from it. Perhaps in the early days of D, it just seemed too weird to have `return` parameters, but now with ref safety, they are better justified. But if they'd been there back then, `inout` probably wouldn't exist, since you can just build it in its current form from `const` and `return`.char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.That's a very interesting observation. I never liked the name `inout`, as it doesn't describe what it does. The only downside I see is that it's more magic, because nothing on the return type says its mutability is going to depend on an argument. I think Kenji also had additional plans for `inout`, related to uniqueness. There was a PR. Better ask him whether it's going to be compatible.
Mar 16 2015
On 16/03/2015 14:17, Zach the Mystic wrote:char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.inout can be used for local variables too.
Mar 17 2015
On Tuesday, 17 March 2015 at 12:02:15 UTC, Nick Treleaven wrote:On 16/03/2015 14:17, Zach the Mystic wrote:Yeah that might be a use for it. inout(T*) fun(inout(T*) t) { inout(T*) x = t; return x; } --> T* gun(return const T* t) { const(T*) x = t; return x; } To be fully viable, `return` would have to be secretly recorded as part of the `x's type, so that the compiler could forgive returning it to a non-const. But the compiler should probably track that `x` is copied from `t` anyway, so that it can verify `return t` when it returns `x`, and the same information would be used to forgive `x's constness. But yeah, there might still be a use for `inout`.char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy.inout can be used for local variables too.
Mar 17 2015
To be fully viable, `return` would have to be secretly recorded as part of the `x's type, so that the compiler could forgive returning it to a non-const. But the compiler should probably track that `x` is copied from `t` anyway, so that it can verify `return t` when it returns `x`, and the same information would be used to forgive `x's constness. But yeah, there might still be a use for `inout`.Why is this ability important? It feels like trying to distort non-templates into templates. Is this the alternative to using templates or repeating yourself or are there other important aspects to it?
Mar 17 2015
On Tuesday, 17 March 2015 at 18:27:01 UTC, ixid wrote:I don't know for sure. I think the main point of `inout` is to avoid returning a copy of a reference that's mutable and assigning it to an immutable. When there is no copy of a reference (i.e. it's unique), or if you know that all possible copies are immutable, there's no problem. Even an immutable reference with lifetime shorter than the `const` value it copies is okay. In other words, it seems like there are a lot of cases where you can assign something that returns a regular `T*` to an `immutable(T*)` safely.To be fully viable, `return` would have to be secretly recorded as part of the `x's type, so that the compiler could forgive returning it to a non-const. But the compiler should probably track that `x` is copied from `t` anyway, so that it can verify `return t` when it returns `x`, and the same information would be used to forgive `x's constness. But yeah, there might still be a use for `inout`.Why is this ability important? It feels like trying to distort non-templates into templates. Is this the alternative to using templates or repeating yourself or are there other important aspects to it?
Mar 17 2015