• 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

"Zach the Mystic" <reachzach gggmail.com> writes:

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.

ketmar <ketmar ketmar.no-ip.org> writes:

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!=

"Zach the Mystic" <reachzach gggmail.com> writes:

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:

 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!

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.

ketmar <ketmar ketmar.no-ip.org> writes:

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:
 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!

=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.

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.=

"Zach the Mystic" <reachzach gggmail.com> writes:

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:

 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:

 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!

 
 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.

 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.

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.

ketmar <ketmar ketmar.no-ip.org> writes:

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!=

"Zach the Mystic" <reachzach gggmail.com> writes:

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.

ketmar <ketmar ketmar.no-ip.org> writes:

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:
 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.

your change includes both observation and syntax change. i don't want to=20
separate them.

 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.=

"Idan Arye" <GenericNPC gmail.com> writes:

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...

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

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:
 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...

It's been experimentally introduced by DIP25:
http://wiki.dlang.org/DIP25

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

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.

"Zach the Mystic" <reachzach gggmail.com> writes:

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:
 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.

`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`.

Nick Treleaven <ntrel-pub mybtinternet.com> writes:

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.

"Zach the Mystic" <reachzach gggmail.com> writes:

On Tuesday, 17 March 2015 at 12:02:15 UTC, Nick Treleaven wrote:
 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.

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`.

"ixid" <adamsibson hotmail.com> writes:

 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?

"Zach the Mystic" <reachzach gggmail.com> writes:

On Tuesday, 17 March 2015 at 18:27:01 UTC, ixid wrote:
 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?

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.