2016-04-15 22:41 GMT+09:00 Andrei Alexandrescu via Digitalmars-d < [email protected]>:
> On 04/15/2016 06:50 AM, Kenji Hara via Digitalmars-d wrote: > >> >> >> You should recall the history of inout. >> http://wiki.dlang.org/DIP2 >> >> At first, It has designed to temporarily squash mutable/const/immutable >> qualifiers on function argument inside function body. Therefore when >> inout qualifier appears in function return type, but doesn't on >> parameter types, we defined it an error. >> >> However, I concluded that we can remove the restriction. When an inout >> object arises from thin air, no one holds the qualifier of its real >> instance. It means, the returned inout object can be converted to >> arbitrary qualifiers without type system breaking. >> >> Two years ago I opened an enhancement issue: >> https://issues.dlang.org/show_bug.cgi?id=13006 >> >> And posted a pull request. >> https://github.com/D-Programming-Language/dmd/pull/3740 >> > > I do recall the history. The enhancement is sensible in a frame of mind > "we need to keep inout" but I'm looking at top level and thinking, crap we > can put up with a little duplication if we get rid of inout. It's just a > prime example of apparently simple idea gone bonkers. > > In all of my recent code I've avoided inout and didn't miss it one bit. > There's no need for it - I replace it with one-liners that forward to > template functions, which in turn deduce qualifiers and all is great. Didn't you use array.dup until now? It's a good example to handle qualifiers with inout. It's not sensible at all, inout is already well-defined and has much power in D's type system. Removing it is just a foolish idea. If you worry the future of Phobos written in D, first you would need to think about @safe. It's yet not well defined/implemented by compiler, and many Phobos code are marked as @trusted. Does it has lower priority than complain to a small hack for the *current* inout limitation? I just cannot agree your argument. Kenji Hara
