Re: How does one get to the root of a package in ddox?
Am 16.04.2016 um 07:38 schrieb Sönke Ludwig: Am 15.04.2016 um 22:38 schrieb Andrei Alexandrescu: Say you're on https://dlang.org/library/std/range/primitives.html and try to find your way to https://dlang.org/library/std/range.html. Clicking on "range" in the navigation panel doesn't help - it just collapses/expands the tree branch. What's the design here? Thanks, Andrei Oh yeah, this is something that has been bugging me for a while, but I haven't got around to fix. The problem is that due to the way the navigation menu currently works, there need to be two entries for packages that have a package.d (the upper one will snap in/out while the bottom one will open the package documentation). We'd have to change the UI to be more like a classical tree control with a +/- box at the left. Alternatively, the package.d entry could be put as the first child item of its package and get a special name (e.g. "Package documentation").
Re: How does one get to the root of a package in ddox?
Am 15.04.2016 um 22:38 schrieb Andrei Alexandrescu: Say you're on https://dlang.org/library/std/range/primitives.html and try to find your way to https://dlang.org/library/std/range.html. Clicking on "range" in the navigation panel doesn't help - it just collapses/expands the tree branch. What's the design here? Thanks, Andrei Oh yeah, this is something that has been bugging me for a while, but I haven't got around to fix. The problem is that due to the way the navigation menu currently works, there need to be two entries for packages that have a package.d (the upper one will snap in/out while the bottom one will open the package documentation). We'd have to change the UI to be more like a classical tree control with a +/- box at the left.
Re: What is going on in this code?
On Friday, April 15, 2016 21:16:44 Jonathan M Davis via Digitalmars-d wrote: > On Thursday, April 14, 2016 09:31:25 Steven Schveighoffer via Digitalmars-d > > wrote: > > That is awful. > > > > I propose we make slicing such a return value implicitly an error. I > > can't think of a valid reason for allowing it. > > > > I'm not the only one: https://issues.dlang.org/show_bug.cgi?id=12625 > > Totally agree, though I wish that we could take it one step further and get > rid of the implicit slicing of static arrays. It's an unsafe feature, and > once https://issues.dlang.org/show_bug.cgi?id=8838 has been fixed, and > slicing a static array is flagged as @system, allowing the implicit slicing > makes it really easy to miss that it's happening, and if multiple @system > operations are happening in a function, the slicing of the static array > could easily be missed by a programmer verifying the safety of the code in > order to mark it with @trusted, whereas if the slice were explicit, it would > be obvious. Unfortunately, I'm willing to bet that there's no way that > Walter would give his okay on making the implicit slicing illegal because > of how much code would break as a result. Well, for whatever it's worth, I created an enhancement request. Maybe we'll get lucky and be able to talk Walter into it: https://issues.dlang.org/show_bug.cgi?id=15932 8838 and 12625 still need to be fixed regardless, but if we got rid of the implicit slicing of static arrays, then you'd at least always be able to see what's going on and more easily catch slicing-related bugs. - Jonathan M Davis
Re: What is going on in this code?
On Thursday, April 14, 2016 09:31:25 Steven Schveighoffer via Digitalmars-d wrote: > That is awful. > > I propose we make slicing such a return value implicitly an error. I > can't think of a valid reason for allowing it. > > I'm not the only one: https://issues.dlang.org/show_bug.cgi?id=12625 Totally agree, though I wish that we could take it one step further and get rid of the implicit slicing of static arrays. It's an unsafe feature, and once https://issues.dlang.org/show_bug.cgi?id=8838 has been fixed, and slicing a static array is flagged as @system, allowing the implicit slicing makes it really easy to miss that it's happening, and if multiple @system operations are happening in a function, the slicing of the static array could easily be missed by a programmer verifying the safety of the code in order to mark it with @trusted, whereas if the slice were explicit, it would be obvious. Unfortunately, I'm willing to bet that there's no way that Walter would give his okay on making the implicit slicing illegal because of how much code would break as a result. - Jonathan M Davis
Re: Who wore it better?
On Friday, April 15, 2016 13:46:24 Andrei Alexandrescu via Digitalmars-d wrote: > On 04/15/2016 01:31 PM, Namespace wrote: > > Since it is a template: Why these attributes: @trusted pure nothrow ? > > @trusted is not inferrable, the others are type-independent and nice for > the documentation. -- Andrei Yes. I definitely think that it should be standard policy in Phobos (if not D code in general) to only use attribute inference when it's actually required. Without attribute inference, attributes and templates really wouldn't work together (which is why we have it), but the cost is that you don't know what the actual attributes are without compiling the code. So, while some folks may not like the extra typing, I think that it's clearly better for everyone who has to look at or maintain a function and/or its documentation to know what its attributes are by looking just at it, even if it's a little bit of extra work for the person who writes the function initially. I honestly wish that we hadn't added attribute inference to auto return functions, since I think that it's just enabling a bad practice. - Jonathan M Davis
Re: Dead link finding automation
On Saturday, 16 April 2016 at 01:13:24 UTC, Andrei Alexandrescu wrote: On 04/15/2016 08:38 PM, Vladimir Panteleev wrote: The macros we use in our documentation are not meant for the URL structure that DDox uses. This incompatibility creates broken links. Can we build ddox with specific macros? We use that technique with latex etc. -- Andrei Yep, and we do that: https://github.com/dlang/dlang.org/blob/master/std-ddox.ddoc https://github.com/dlang/dlang.org/blob/master/std-ddox-override.ddoc Generating URLs is not always necessary with DDox, as it automatically turns fully-qualified names into links.
Re: Recursive vs. iterative constraints
On Friday, April 15, 2016 22:42:55 Andrei Alexandrescu via Digitalmars-d wrote: > So the constraint on chain() is: > > Ranges.length > 0 && > allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) && > !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == > void) > > Noice. Now, an alternative is to express it as a recursive constraint: > > (Ranges.length == 1 && isInputRange!(Unqual!(Ranges[0]))) > >(Ranges.length == 2 && > isInputRange!(Unqual!(Ranges[0])) && > isInputRange!(Unqual!(Ranges[1])) && > !is(CommonType!(ElementType!(Ranges[0]), ElementType!(Ranges[1])) > == void)) > >|| is(typeof(chain(rs[0 .. $ / 2], chain(rs[$ / 2 .. $] > > In the latter case there's no need for additional helpers but the > constraint is a bit more bulky. > > Pros? Cons? Preferences? The first one is way cleaner IMHO. - Jonathan M Davis
Re: Recursive vs. iterative constraints
On Saturday, 16 April 2016 at 02:42:55 UTC, Andrei Alexandrescu wrote: So the constraint on chain() is: Ranges.length > 0 && allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) && !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == void) Noice. Now, an alternative is to express it as a recursive constraint: (Ranges.length == 1 && isInputRange!(Unqual!(Ranges[0]))) || (Ranges.length == 2 && isInputRange!(Unqual!(Ranges[0])) && isInputRange!(Unqual!(Ranges[1])) && !is(CommonType!(ElementType!(Ranges[0]), ElementType!(Ranges[1])) == void)) || is(typeof(chain(rs[0 .. $ / 2], chain(rs[$ / 2 .. $] In the latter case there's no need for additional helpers but the constraint is a bit more bulky. Pros? Cons? Preferences? Andrei The former, definitely. The only helper function you're getting rid of that I see is allSatisfy, which describes the constraint very well. The recursive constraint obscures what the intended constraint is (that the passed types are input ranges with a common type) behind the recursion.
Recursive vs. iterative constraints
So the constraint on chain() is: Ranges.length > 0 && allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) && !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == void) Noice. Now, an alternative is to express it as a recursive constraint: (Ranges.length == 1 && isInputRange!(Unqual!(Ranges[0]))) || (Ranges.length == 2 && isInputRange!(Unqual!(Ranges[0])) && isInputRange!(Unqual!(Ranges[1])) && !is(CommonType!(ElementType!(Ranges[0]), ElementType!(Ranges[1])) == void)) || is(typeof(chain(rs[0 .. $ / 2], chain(rs[$ / 2 .. $] In the latter case there's no need for additional helpers but the constraint is a bit more bulky. Pros? Cons? Preferences? Andrei
Re: Who wore it better?
On 04/15/2016 05:27 PM, Steven Schveighoffer wrote: On 4/15/16 5:01 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:45 PM, Steven Schveighoffer wrote: On 4/15/16 4:34 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:16 PM, Steven Schveighoffer wrote: If you find such advertisement useless, you of course do not need inout or const. Let's not exaggerate by putting them together. -- Andrei This is not an exaggeration. Jesus. C++ has const without inout. We used to have const without inout - and we probably should again. -- Andrei "C++ has it" is a terrible argument. You're losing track of the thread of the argument. It's not an argument, it's the factual correct refutation of your wrong claim. If you care about advertisement, you can't use templates to advertise whether something is const or not. Your solution is "let's use templates instead". That works, but obviously, compiler will let you molest whatever data you want. Then advertisement is done with documentation and trust. C++ simply doesn't have that capability to advertise const for the things inout can, but also const isn't as restrictive in C++, so you can put const on things that aren't really const. IIRC Walter says C++ const is useless for guarantees (and I agree with that). Tell me what the benefits of const are. Pretty much all the arguments you are saying for getting rid of inout (that don't involve corner cases we can fix) can be used to say we should get rid of const too. Why stop getting rid of complexity at inout? The simple answer is const pays enough, inout doesn't. Anyhow this meandering is the kiss of death - this exchange is becoming a time-wasting back and forth, exactly the kind I promised myself to not get involved in. I'll keep your good points in mind when deciding whether we should rid D of inout. Thanks, Andrei
Re: Dead link finding automation
On 04/15/2016 08:38 PM, Vladimir Panteleev wrote: External links are a different issue. They can't be tested in the autotester (at least not fail the build), otherwise a site we link to going (temporarily) down means our master is broken. They would need special treatment, e.g. report them as some form of warnings but don't fail them. If the link fails, should have a Google cache. If not, that's an error :o). -- Andrei
Re: Dead link finding automation
On 04/15/2016 08:38 PM, Vladimir Panteleev wrote: The macros we use in our documentation are not meant for the URL structure that DDox uses. This incompatibility creates broken links. Can we build ddox with specific macros? We use that technique with latex etc. -- Andrei
Re: On the origins of github.com/D-Programming-Language
On 04/15/2016 08:06 PM, Vladimir Panteleev wrote: On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong. Many thanks, Vladimir! -- Andrei
RefCounted / DMD bug
I'm getting a strange assertion/crash involving RefCounted and
I've reduced it down to the isolated case (see below). This is
with D 2.071 and requires this version to compile.
I'm wondering if there is something I wrong in the way I'm using
RefCounted. I'm using using it to pass RC value types through
chained calls, which should be ok. This seems more like a
compiler bug due to the strangeness of the fix lines. The
compiler seems confused by the two methods names query in
separate classes (removing the first def and the issue goes
away). The 2nd fix is on an unused RC. It could also be that
there is underlying memory corruption that is intermittent and I
just haven't found the problem.
This is a big issue for my design so hopefully the problem can be
identified.
erik
import std.typecons;
struct BasicDatabase(Impl) {
alias Connection = BasicConnection!Impl;
this(string defaultURI) {data = Data(null);}
auto connection() {return Connection(this);}
private:
alias RefCounted!(Impl, RefCountedAutoInitialize.no) Data;
Data data;
}
struct BasicConnection(Impl) {
alias Statement = BasicStatement!Impl;
alias Database = BasicDatabase!Impl;
auto statement() {return Statement(this);}
auto query() {return statement().query();} // === remove to
fix 1
this(Database db) {
//database = db;
data = Data(&db.data.refCountedPayload());
}
private:
alias RefCounted!(Impl, RefCountedAutoInitialize.no) Data;
Database database; // === remove to fix 2
Data data;
}
struct BasicStatement(Impl) {
alias Connection = BasicConnection!Impl;
alias Result = BasicResult!Impl;
this(Connection c) {
con = c;
data = Data(&con.data.refCountedPayload());
}
auto query() {return Result(this);}
private:
alias RefCounted!(Impl, RefCountedAutoInitialize.no) Data;
Data data;
Connection con;
}
struct BasicResult(Impl) {
alias Statement = BasicStatement!Impl;
this(Statement s) {
stmt = s;
data = Data(&stmt.data.refCountedPayload());
}
private:
alias RefCounted!(Impl, RefCountedAutoInitialize.no) Data;
Statement stmt;
Data data;
}
struct Payload {
this(Payload *p) {}
}
void main() {
auto db = BasicDatabase!Payload("source");
auto s = db.connection().statement();
auto r = s.query();
}
core.exception.AssertError@std/typecons.d(4860): Assertion failure
4 bug 0x0001063c3f20
_d_assert + 104
5 bug 0x0001063dc3ca void
std.typecons.__assert(int) + 38
6 bug 0x0001063bae4e
nothrow @nogc void
std.typecons.__T10RefCountedTS3bug7PayloadVE3std8typecons24RefCountedAutoInitializei0Z.RefCounted.__dtor() + 54
7 bug 0x0001063ba8c5
nothrow @nogc void
bug.BasicStatement!(bug.Payload).BasicStatement.__fieldDtor() + 29
8 bug 0x0001063ba096 _Dmain
+ 210
9 bug 0x0001063d48b3
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
10 bug 0x0001063d47e7 void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 35
11 bug 0x0001063d4858 void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() + 44
12 bug 0x0001063d47e7 void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 35
13 bug 0x0001063d474d
_d_run_main + 497
14 bug 0x0001063ba19b main +
15
15 libdyld.dylib 0x7fff977f35ac start
+ 0
16 ??? 0x 0x0 + 0
bug(39873,0x7fff7838d000) malloc: *** error for object
0x7fdea9c03d18: incorrect checksum for freed object - object was
probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
Re: On the origins of github.com/D-Programming-Language
On 4/15/16 5:06 PM, Vladimir Panteleev via Digitalmars-d wrote: On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong. I've updated the auto-tester to point directly at the new organization. About the only thing I haven't seen go through yet is a merge. But testing seems to be going just fine.
Re: Dead link finding automation
On 4/15/16 5:38 PM, Vladimir Panteleev via Digitalmars-d wrote: On Friday, 15 April 2016 at 18:25:58 UTC, Andrei Alexandrescu wrote: Can we automate stuff like https://issues.dlang.org/show_bug.cgi?id=15929? There are quite a few tools around, not to mention we could easily roll our own. Who'd like to take this project? Thx! -- Andrei It's something I've been thinking about for a while. This particular case is a DDox deficiency. The macros we use in our documentation are not meant for the URL structure that DDox uses. This incompatibility creates broken links. People have stepped up with PRs to replace them with better macros, which will work in DDox as well, so it's an area of active improvement. chmgen reports broken internal links (for stuff that goes into the CHM, which is based on the DDoc Phobos documentation format, thus it wouldn't find the above broken DDox link). I've been planning into integrating it into the documentation tester, so that new broken internal links result in a test failure. External links are a different issue. They can't be tested in the autotester (at least not fail the build), otherwise a site we link to going (temporarily) down means our master is broken. They would need special treatment, e.g. report them as some form of warnings but don't fail them. You don't want the link checker checking external links directly anyway, that'd be a nice way to use the tester as an attack vector. Instead, you could have the tester accumulate a set of external links and check them separately maybe once a day or whatever. It'd also be a good way to detect new external links and give reviewers a chance to make sure it's a site we want to rely on being available enough.
Re: Dead link finding automation
On Friday, 15 April 2016 at 18:25:58 UTC, Andrei Alexandrescu wrote: Can we automate stuff like https://issues.dlang.org/show_bug.cgi?id=15929? There are quite a few tools around, not to mention we could easily roll our own. Who'd like to take this project? Thx! -- Andrei It's something I've been thinking about for a while. This particular case is a DDox deficiency. The macros we use in our documentation are not meant for the URL structure that DDox uses. This incompatibility creates broken links. People have stepped up with PRs to replace them with better macros, which will work in DDox as well, so it's an area of active improvement. chmgen reports broken internal links (for stuff that goes into the CHM, which is based on the DDoc Phobos documentation format, thus it wouldn't find the above broken DDox link). I've been planning into integrating it into the documentation tester, so that new broken internal links result in a test failure. External links are a different issue. They can't be tested in the autotester (at least not fail the build), otherwise a site we link to going (temporarily) down means our master is broken. They would need special treatment, e.g. report them as some form of warnings but don't fail them.
Re: On the origins of github.com/D-Programming-Language
On Saturday, 16 April 2016 at 00:14:46 UTC, Steven Schveighoffer wrote: BTW, do I need to be a member of the redirect group? I was asked to join, but I think it may not matter. Yeah, I indeed don't think it matters. In fact that group should probably have as few people as possible, to avoid anyone accidentally creating a repository with the same name as a dlang repository, which would destroy the redirect.
Re: On the origins of github.com/D-Programming-Language
On 4/15/16 8:13 PM, Vladimir Panteleev wrote: On Saturday, 16 April 2016 at 00:11:53 UTC, Steven Schveighoffer wrote: On 4/15/16 8:06 PM, Vladimir Panteleev wrote: On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong. This is awesome! Makes me want to delete and re-clone everything :) Well that's a bit drastic when you can just change the remotes, isn't it :) Probably. BTW, do I need to be a member of the redirect group? I was asked to join, but I think it may not matter. -Steve
Re: On the origins of github.com/D-Programming-Language
On Saturday, 16 April 2016 at 00:11:53 UTC, Steven Schveighoffer wrote: On 4/15/16 8:06 PM, Vladimir Panteleev wrote: On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong. This is awesome! Makes me want to delete and re-clone everything :) Well that's a bit drastic when you can just change the remotes, isn't it :)
Re: On the origins of github.com/D-Programming-Language
On 4/15/16 8:06 PM, Vladimir Panteleev wrote: On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong. This is awesome! Makes me want to delete and re-clone everything :) -Steve
Re: On the origins of github.com/D-Programming-Language
On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong.
perfect hash map in visual D
https://github.com/BBasile/IsItThere https://issues.dlang.org/show_bug.cgi?id=15901 when you want bro ;)
Re: So what does (inout int = 0) do?
On 4/15/16 6:31 PM, Timon Gehr wrote: On 15.04.2016 23:56, Steven Schveighoffer wrote: Impossible or difficult to do with the current implementation? ... What I'm saying is that the check that is currently implemented is not adequate for the new case. This is not terribly important though. The point was that there needs to be a design effort beyond lifting the limitation, and you seemed to claim that the current implementation already takes care of the presented issue, which is not the case. Your ideas are sound though. I'm sorry, should have put on my standard disclaimer that I am not a compiler writer :) I actually have no idea how this is done in the compiler, just how a compiler should behave as I understand it in my head. I may have said this incorrectly. The language itself wouldn't really be that much more complex. It's the cost of understanding what each of the different inout pools mean. They would just be named parameters to the function on the type system level, similar to template arguments but not causing repeated instantiation. Right, but again: these are named by the writer of the template, not the language, right? In that case, any identifier becomes a modifier. Or are you thinking of something different? The benefit would be quite small, whereas there are obvious places inout makes sense -- the 'this' parameter and the return value. ... The return value might contain more than one pointer, and functions often have more than one parameter. Of course, but the transference of mutability from parameter to return value is the obvious draw of such a wildcard. In most cases, there is only one return value, and therefore only one pool that needs to be handled. ref/out parameters can serve as alternate returns as well as composed types. It's not that functions don't have multiple returns with their own inout, but I don't think it's very common. As we get more and more obscure, the cost/benefit ratio for complexity vs. power gets higher. And already people don't like where we are right now with it. Then there is the syntax that would be required, I'm not sure what that looks like. ... Anything that is analogous to template parameters, e.g. an additional set of arguments with a different delimiter. Many workable possibilities. Anyway, it is unlikely to happen. Especially given the discussion happening here, I agree. Humans are creatures of habit and familiarity. To allow each library to define what words mean what for modifiers would be really difficult to deal with. I don't see how the library would do that. Just throwing a strawman out there: void foo(bingo = inout, zingo = inout)(bingo(int)* x, zingo(int)* y) So inside foo, bingo is one flavor of inout, zingo is another. This could vary library to library, function to function. It would work, and be sound design. I would just hate it is all :) Perhaps you have a better system in mind? -Steve
Re: So what does (inout int = 0) do?
On 15.04.2016 23:56, Steven Schveighoffer wrote:
On 4/15/16 5:17 PM, Timon Gehr wrote:
On 15.04.2016 22:47, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
...
Yes, there is. Semantic analysis sees the parameter types before it sees
the body.
I don't know what the current implementation sees the function as doing.
The way I look at it, the function context is like an extra parameter to
the inner function. If it contains inout data,
Rather, when the inout data is actually accessed.
then that needs to be
taken into account if the inner function has additional inout parameters.
...
That's sensible, of course. The current implementation is a lot more
conservative though.
For example:
inout(int) *x;
inout(int) *foo(inout int) {return x;}
foo is really taking 2 parameters: y and the context pointer that
contains x. It almost looks like this:
inout(int) *foo(inout int, ref inout(int) *x) { return x;}
call this with: foo(1, x)
And it won't compile.
However, call it with: foo(inout(int)(1), x);
and it should be fine, returning an inout(int)*.
They should be treated the same once the function starts compiling.
...
I think I have stated clearly why this is impossible. :P
Impossible or difficult to do with the current implementation?
...
What I'm saying is that the check that is currently implemented is not
adequate for the new case. This is not terribly important though. The
point was that there needs to be a design effort beyond lifting the
limitation, and you seemed to claim that the current implementation
already takes care of the presented issue, which is not the case.
Your ideas are sound though.
At the point where we need to tag multiple pools of inout parameters,
the complexity of the language doesn't justify the benefits.
...
I think this is a funny place to draw the line, but I guess this is a
matter of taste.
I may have said this incorrectly. The language itself wouldn't really be
that much more complex. It's the cost of understanding what each of the
different inout pools mean.
They would just be named parameters to the function on the type system
level, similar to template arguments but not causing repeated instantiation.
The benefit would be quite small, whereas
there are obvious places inout makes sense -- the 'this' parameter and
the return value.
...
The return value might contain more than one pointer, and functions
often have more than one parameter.
Then there is the syntax that would be required, I'm not sure what that
looks like.
...
Anything that is analogous to template parameters, e.g. an additional
set of arguments with a different delimiter. Many workable
possibilities. Anyway, it is unlikely to happen.
We could make it possible, for instance, to templatize the mutability
modifier instead of using a specific keyword. Then you could have
foo(int)[]. Then I think you could do all this (and scrap inout), but I
wouldn't want to work in that language.
Well, that is precisely the way that languages with real type systems
address issues like this one. D has many others like it.
Aye, solutions like Rebindable, which is pretty much a failure IMO, show
how lack of expressiveness in the core language can't be easily
substituted.
Note that for type systems, complexity and expressiveness do not
necessarily correlate.
Humans are creatures of habit and familiarity. To allow each library to
define what words mean what for modifiers would be really difficult to
deal with.
-Steve
I don't see how the library would do that.
Re: So what does (inout int = 0) do?
On 4/15/16 5:17 PM, Timon Gehr wrote:
On 15.04.2016 22:47, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
...
Yes, there is. Semantic analysis sees the parameter types before it sees
the body.
I don't know what the current implementation sees the function as doing.
The way I look at it, the function context is like an extra parameter to
the inner function. If it contains inout data, then that needs to be
taken into account if the inner function has additional inout parameters.
For example:
inout(int) *x;
inout(int) *foo(inout int) {return x;}
foo is really taking 2 parameters: y and the context pointer that
contains x. It almost looks like this:
inout(int) *foo(inout int, ref inout(int) *x) { return x;}
call this with: foo(1, x)
And it won't compile.
However, call it with: foo(inout(int)(1), x);
and it should be fine, returning an inout(int)*.
They should be treated the same once the function starts compiling.
...
I think I have stated clearly why this is impossible. :P
Impossible or difficult to do with the current implementation?
At the point where we need to tag multiple pools of inout parameters,
the complexity of the language doesn't justify the benefits.
...
I think this is a funny place to draw the line, but I guess this is a
matter of taste.
I may have said this incorrectly. The language itself wouldn't really be
that much more complex. It's the cost of understanding what each of the
different inout pools mean. The benefit would be quite small, whereas
there are obvious places inout makes sense -- the 'this' parameter and
the return value.
Then there is the syntax that would be required, I'm not sure what that
looks like.
We could make it possible, for instance, to templatize the mutability
modifier instead of using a specific keyword. Then you could have
foo(int)[]. Then I think you could do all this (and scrap inout), but I
wouldn't want to work in that language.
Well, that is precisely the way that languages with real type systems
address issues like this one. D has many others like it.
Aye, solutions like Rebindable, which is pretty much a failure IMO, show
how lack of expressiveness in the core language can't be easily substituted.
Note that for type systems, complexity and expressiveness do not
necessarily correlate.
Humans are creatures of habit and familiarity. To allow each library to
define what words mean what for modifiers would be really difficult to
deal with.
-Steve
Re: Who wore it better?
On 4/15/16 5:01 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:45 PM, Steven Schveighoffer wrote: On 4/15/16 4:34 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:16 PM, Steven Schveighoffer wrote: If you find such advertisement useless, you of course do not need inout or const. Let's not exaggerate by putting them together. -- Andrei This is not an exaggeration. Jesus. C++ has const without inout. We used to have const without inout - and we probably should again. -- Andrei "C++ has it" is a terrible argument. If you care about advertisement, you can't use templates to advertise whether something is const or not. Your solution is "let's use templates instead". That works, but obviously, compiler will let you molest whatever data you want. Then advertisement is done with documentation and trust. C++ simply doesn't have that capability to advertise const for the things inout can, but also const isn't as restrictive in C++, so you can put const on things that aren't really const. IIRC Walter says C++ const is useless for guarantees (and I agree with that). Tell me what the benefits of const are. Pretty much all the arguments you are saying for getting rid of inout (that don't involve corner cases we can fix) can be used to say we should get rid of const too. Why stop getting rid of complexity at inout? -Steve
Re: So what does (inout int = 0) do?
On 15.04.2016 23:03, Andrei Alexandrescu wrote:
On 04/15/2016 04:47 PM, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
So now we get to things like:
void fun() {
inout int ohHello = 42;
...
}
How to explain such a construct? Not to mention globals of that type are
not allowed.
Andrei
It's an int that has not decided yet whether it wants to be mutable,
const or immutable and goes out of scope before it is able to make up
its mind.
Re: So what does (inout int = 0) do?
On 04/15/2016 05:17 PM, Timon Gehr wrote: Well, that is precisely the way that languages with real type systems address issues like this one. D has many others like it. Note that for type systems, complexity and expressiveness do not necessarily correlate. Nicely put on both counts. (Well "real" is semantically sarcastic a bit.) I don't even disagree :o). -- Andrei
Re: So what does (inout int = 0) do?
On 15.04.2016 22:47, Steven Schveighoffer wrote:
On 4/15/16 4:27 PM, Timon Gehr wrote:
On 15.04.2016 22:03, Steven Schveighoffer wrote:
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even
though
I thought it was being helpful when I suggested it). That is,
functions
without inout parameters cannot declare local inout variables. But
this
isn't really necessary, and should be fixed. I will discuss this in my
talk in a few weeks.
...
That's potentially dangerous. What about cases like the following?
void main(){
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a);
int[] z=foo(b);
}
We don't need to guess:
void foo (inout int)
{
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a); // line 9
int[] z=foo(b); // line 10
}
testinout.d(9): Error: modify inout to immutable is not allowed inside
inout function
testinout.d(10): Error: modify inout to mutable is not allowed inside
inout function
I'm very aware of that: https://issues.dlang.org/show_bug.cgi?id=10758
main is not an inout function in the example above. I.e. if we just
change the compiler minimally such as to allow making inout local
variables, the above example will violate immutability guarantees. You
can also imagine cases where the inout local variable is defined only
after the local inout function has been declared and called with a
non-inout argument. At which point does the constraint become active?
etc. We cannot _simply_ allow declaring inout locals.
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
...
Yes, there is. Semantic analysis sees the parameter types before it sees
the body.
They should be treated the same once the function starts compiling.
...
I think I have stated clearly why this is impossible. :P
Note, the =0 part isn't necessary right now, since it's not called.
It's
just used to test if the function can compile.
In short, my opinion on inout is that it has some unnecessary
limitations, which can be removed, and inout will work as mostly
expected. These requirements to work around the limitations will go
away.
...
Other important limitations of inout are e.g.:
- inout variables cannot be fields.
I have a way to make this work.
Without syntax changes?
Can the struct/class instances with inout fields be returned from the
enclosing inout function?
Yes, as long as inout is wrapping inout. We run into this currently with
inout functions that create local types. e.g. emplace.
Obviously inout cannot be unwrapped if it is typed on a field of a
struct or class. So the unwrapping has to result in inout.
...
Ok.
- There can be only one inout in scope.
This is not so much a problem I think.
...
I think it is. It's just not the prevalent limitation one runs in at the
moment. It will be more of a problem once functions can return structs
with inout fields. IMHO compositionality should be ensured for a
language feature from the start.
At the point where we need to tag multiple pools of inout parameters,
the complexity of the language doesn't justify the benefits.
...
I think this is a funny place to draw the line, but I guess this is a
matter of taste.
We could make it possible, for instance, to templatize the mutability
modifier instead of using a specific keyword. Then you could have
foo(int)[]. Then I think you could do all this (and scrap inout), but I
wouldn't want to work in that language.
-Steve
Well, that is precisely the way that languages with real type systems
address issues like this one. D has many others like it.
Note that for type systems, complexity and expressiveness do not
necessarily correlate.
Re: Who wore it better?
On 04/15/2016 04:47 PM, Marco Leise wrote:
Am Fri, 15 Apr 2016 14:48:26 -0400
schrieb Andrei Alexandrescu :
On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
On 4/15/16 1:24 PM, Andrei Alexandrescu wrote:
auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
if (is(typeof(r1.ptr < r2.ptr) == bool))
{
import std.algorithm : min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Who wore it better?
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
import std.algorithm: min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Is that better or worse than the one without inout? -- Andrei
I tend to write functions in the latter style, to avoid
unneeded template instantiations. In this case it also
documents the intent better. Both arrays are of the same type
T and we wont modify the contents.
Thanks, this is a good point that needs keeping in mind.
Even if the compiler can remove binary identical instances
after the fact, the compile time and memory use increases.
It also has implications on debugging. After duplicate
removal, you cannot map a function address to a unique symbol
name any more.
This is perhaps weaker.
Andrei
Re: So what does (inout int = 0) do?
On 04/15/2016 04:47 PM, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
So now we get to things like:
void fun() {
inout int ohHello = 42;
...
}
How to explain such a construct? Not to mention globals of that type are
not allowed.
Andrei
Re: Who wore it better?
On 04/15/2016 04:45 PM, Steven Schveighoffer wrote: On 4/15/16 4:34 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:16 PM, Steven Schveighoffer wrote: If you find such advertisement useless, you of course do not need inout or const. Let's not exaggerate by putting them together. -- Andrei This is not an exaggeration. Jesus. C++ has const without inout. We used to have const without inout - and we probably should again. -- Andrei
Re: So what does (inout int = 0) do?
On 4/15/16 4:27 PM, Timon Gehr wrote:
On 15.04.2016 22:03, Steven Schveighoffer wrote:
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even though
I thought it was being helpful when I suggested it). That is, functions
without inout parameters cannot declare local inout variables. But this
isn't really necessary, and should be fixed. I will discuss this in my
talk in a few weeks.
...
That's potentially dangerous. What about cases like the following?
void main(){
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a);
int[] z=foo(b);
}
We don't need to guess:
void foo (inout int)
{
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a); // line 9
int[] z=foo(b); // line 10
}
testinout.d(9): Error: modify inout to immutable is not allowed inside
inout function
testinout.d(10): Error: modify inout to mutable is not allowed inside
inout function
I'm very aware of that: https://issues.dlang.org/show_bug.cgi?id=10758
main is not an inout function in the example above. I.e. if we just
change the compiler minimally such as to allow making inout local
variables, the above example will violate immutability guarantees. You
can also imagine cases where the inout local variable is defined only
after the local inout function has been declared and called with a
non-inout argument. At which point does the constraint become active?
etc. We cannot _simply_ allow declaring inout locals.
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
They should be treated the same once the function starts compiling.
Note, the =0 part isn't necessary right now, since it's not called.
It's
just used to test if the function can compile.
In short, my opinion on inout is that it has some unnecessary
limitations, which can be removed, and inout will work as mostly
expected. These requirements to work around the limitations will go
away.
...
Other important limitations of inout are e.g.:
- inout variables cannot be fields.
I have a way to make this work.
Without syntax changes?
Can the struct/class instances with inout fields be returned from the
enclosing inout function?
Yes, as long as inout is wrapping inout. We run into this currently with
inout functions that create local types. e.g. emplace.
Obviously inout cannot be unwrapped if it is typed on a field of a
struct or class. So the unwrapping has to result in inout.
- There can be only one inout in scope.
This is not so much a problem I think.
...
I think it is. It's just not the prevalent limitation one runs in at the
moment. It will be more of a problem once functions can return structs
with inout fields. IMHO compositionality should be ensured for a
language feature from the start.
At the point where we need to tag multiple pools of inout parameters,
the complexity of the language doesn't justify the benefits.
We could make it possible, for instance, to templatize the mutability
modifier instead of using a specific keyword. Then you could have
foo(int)[]. Then I think you could do all this (and scrap inout), but I
wouldn't want to work in that language.
-Steve
Re: Who wore it better?
Am Fri, 15 Apr 2016 14:48:26 -0400
schrieb Andrei Alexandrescu :
> On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
> > On 4/15/16 1:24 PM, Andrei Alexandrescu wrote:
> >> auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
> >> if (is(typeof(r1.ptr < r2.ptr) == bool))
> >> {
> >> import std.algorithm : min, max;
> >> auto b = max(r1.ptr, r2.ptr);
> >> auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
> >> return b < e ? b[0 .. e - b] : null;
> >> }
> >>
> >> Who wore it better?
> >
> > inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
> > {
> > import std.algorithm: min, max;
> > auto b = max(r1.ptr, r2.ptr);
> > auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
> > return b < e ? b[0 .. e - b] : null;
> > }
>
> Is that better or worse than the one without inout? -- Andrei
I tend to write functions in the latter style, to avoid
unneeded template instantiations. In this case it also
documents the intent better. Both arrays are of the same type
T and we wont modify the contents.
Even if the compiler can remove binary identical instances
after the fact, the compile time and memory use increases.
It also has implications on debugging. After duplicate
removal, you cannot map a function address to a unique symbol
name any more.
Just my 2¢.
--
Marco
Re: Who wore it better?
On 4/15/16 4:34 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:16 PM, Steven Schveighoffer wrote: If you find such advertisement useless, you of course do not need inout or const. Let's not exaggerate by putting them together. -- Andrei This is not an exaggeration. inout and const have pretty much the same benefits and drawbacks, with only a couple of major differences. The main feature of const/inout is advertisement of non-mutation. Otherwise, we could do with just mutable and immutable + templates. -Steve
How does one get to the root of a package in ddox?
Say you're on https://dlang.org/library/std/range/primitives.html and try to find your way to https://dlang.org/library/std/range.html. Clicking on "range" in the navigation panel doesn't help - it just collapses/expands the tree branch. What's the design here? Thanks, Andrei
Re: Who wore it better?
On 04/15/2016 04:16 PM, Steven Schveighoffer wrote: If you find such advertisement useless, you of course do not need inout or const. Let's not exaggerate by putting them together. -- Andrei
Re: So what does (inout int = 0) do?
On 15.04.2016 22:03, Steven Schveighoffer wrote:
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even though
I thought it was being helpful when I suggested it). That is, functions
without inout parameters cannot declare local inout variables. But this
isn't really necessary, and should be fixed. I will discuss this in my
talk in a few weeks.
...
That's potentially dangerous. What about cases like the following?
void main(){
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a);
int[] z=foo(b);
}
We don't need to guess:
void foo (inout int)
{
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a); // line 9
int[] z=foo(b); // line 10
}
testinout.d(9): Error: modify inout to immutable is not allowed inside
inout function
testinout.d(10): Error: modify inout to mutable is not allowed inside
inout function
I'm very aware of that: https://issues.dlang.org/show_bug.cgi?id=10758
main is not an inout function in the example above. I.e. if we just
change the compiler minimally such as to allow making inout local
variables, the above example will violate immutability guarantees. You
can also imagine cases where the inout local variable is defined only
after the local inout function has been declared and called with a
non-inout argument. At which point does the constraint become active?
etc. We cannot _simply_ allow declaring inout locals.
Note, the =0 part isn't necessary right now, since it's not called. It's
just used to test if the function can compile.
In short, my opinion on inout is that it has some unnecessary
limitations, which can be removed, and inout will work as mostly
expected. These requirements to work around the limitations will go
away.
...
Other important limitations of inout are e.g.:
- inout variables cannot be fields.
I have a way to make this work.
Without syntax changes?
Can the struct/class instances with inout fields be returned from the
enclosing inout function?
This is actually the most major sticking
point in inout.
The only correct thing is to keep is that globals/static variables
cannot be typed inout.
- There can be only one inout in scope.
This is not so much a problem I think.
...
I think it is. It's just not the prevalent limitation one runs in at the
moment. It will be more of a problem once functions can return structs
with inout fields. IMHO compositionality should be ensured for a
language feature from the start.
Re: So what does (inout int = 0) do?
On 4/15/16 4:08 PM, Andrei Alexandrescu wrote: On 04/15/2016 04:03 PM, Steven Schveighoffer wrote: I have a way to make this work. This is actually the most major sticking point in inout. The only correct thing is to keep is that globals/static variables cannot be typed inout. Another special case? The only correct thing is to simplify the language to everybody's benefit. -- Andrei This is not a special case any more than disallowing access of shared data from a pure function is a special case. In fact, you could allow inout variables as static or globals, but just couldn't copy them to local inout variables (except full value types). The point is that between 2 different calls to inout, the wrapper means something different. A global/static persists between calls. -Steve
Re: Who wore it better?
On 4/15/16 4:05 PM, Andrei Alexandrescu wrote:
On 04/15/2016 03:13 PM, Steven Schveighoffer wrote:
On 4/15/16 2:48 PM, Andrei Alexandrescu wrote:
On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure
nothrow
{
import std.algorithm: min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Is that better or worse than the one without inout? -- Andrei
Better. It generates one implementation for all 9 combinations of
mutability. Yours generates 9 identical binary functions.
A valid but weak argument. There's been long talk about eliminating
binary identical functions in the front end (some linkers already do
it). That would be the real solution that would help cases unrelated to
inout, too.
The main argument is this:
auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
Can you tell, does overlap modify any data in r1 or r2?
If you find such advertisement useless, you of course do not need inout
or const.
And yours possibly depends on a bug:
https://issues.dlang.org/show_bug.cgi?id=15930
Red herring. Fixing the bug shouldn't break that code.
I don't know what the bug is. That's why I said "possibly." I was
surprised your code compiled with both const/mutable parameters, but
then I found the bug. It's possible it could be fixed and become
correct. I'm not sure.
-Steve
Re: So what does (inout int = 0) do?
On 4/15/16 4:03 PM, Andrei Alexandrescu wrote: On 04/15/2016 03:44 PM, Steven Schveighoffer wrote: I assure you, these limitations were self-imposed. I insisted on them, without realizing that they would cause problems with generic code. I thought they would be good "lint" detection. https://issues.dlang.org/show_bug.cgi?id=3748 Problem is we could have other problems once we fix those. As you just showed, it has already happened. If you look at the core of what inout actually is (a type modifier placeholder), we can simplify how to think about it, and how to implement it. These "requirements" were just extra helpful things that would flag valid, but (naively assumed) pointless code. Turns out, templates generate lots of pointless code (that is typically optimized away in the type system or the optimizer). I hope to make this clear in my talk at dconf. We should really do away with the cowboy style of designing language, which sadly Walter and I have been guilty of too often in the past. The slow but sure accretion of complexity of inout is a textbook example of where that leads. I actually agree, someone with as little experience as I had should not have been listened to when making such a feature :) If I could do it over again, I would still want this feature, but obviously, we could make sane simple rules for it. They are actually quite easy to understand. -Steve
Re: So what does (inout int = 0) do?
On 04/15/2016 04:03 PM, Steven Schveighoffer wrote: I have a way to make this work. This is actually the most major sticking point in inout. The only correct thing is to keep is that globals/static variables cannot be typed inout. Another special case? The only correct thing is to simplify the language to everybody's benefit. -- Andrei
Re: Who wore it better?
On 04/15/2016 03:13 PM, Steven Schveighoffer wrote:
On 4/15/16 2:48 PM, Andrei Alexandrescu wrote:
On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure
nothrow
{
import std.algorithm: min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Is that better or worse than the one without inout? -- Andrei
Better. It generates one implementation for all 9 combinations of
mutability. Yours generates 9 identical binary functions.
A valid but weak argument. There's been long talk about eliminating
binary identical functions in the front end (some linkers already do
it). That would be the real solution that would help cases unrelated to
inout, too.
And yours possibly depends on a bug:
https://issues.dlang.org/show_bug.cgi?id=15930
Red herring. Fixing the bug shouldn't break that code.
Andrei
Re: So what does (inout int = 0) do?
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even though
I thought it was being helpful when I suggested it). That is, functions
without inout parameters cannot declare local inout variables. But this
isn't really necessary, and should be fixed. I will discuss this in my
talk in a few weeks.
...
That's potentially dangerous. What about cases like the following?
void main(){
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a);
int[] z=foo(b);
}
We don't need to guess:
void foo (inout int)
{
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a); // line 9
int[] z=foo(b); // line 10
}
testinout.d(9): Error: modify inout to immutable is not allowed inside
inout function
testinout.d(10): Error: modify inout to mutable is not allowed inside
inout function
Note, the =0 part isn't necessary right now, since it's not called. It's
just used to test if the function can compile.
In short, my opinion on inout is that it has some unnecessary
limitations, which can be removed, and inout will work as mostly
expected. These requirements to work around the limitations will go away.
...
Other important limitations of inout are e.g.:
- inout variables cannot be fields.
I have a way to make this work. This is actually the most major sticking
point in inout.
The only correct thing is to keep is that globals/static variables
cannot be typed inout.
- There can be only one inout in scope.
This is not so much a problem I think.
-Steve
Re: So what does (inout int = 0) do?
On 04/15/2016 03:44 PM, Steven Schveighoffer wrote: No, because it's not sound. you cannot cast to const through 2+ indirections. However inout works there. That is correct, a classic... thanks for getting me straight. I think the point of Kenji's argument is that inout's current limitations are what you are bumping into, and those limitations are unnecessary and arbitrary. We can make inout better and more consistent. Pretty easily actually. We can certainly fix the inout int = 0 problem. I'm not sure - at all in fact. This is at the tail of a sequence of changes of inout, and there is a history of such mini-designs leading to complications, regressions, and further mini-designs. It's the wolf that eats the dog that eats the cat that eats the mouse. We fix this and there's another and then another and then another. It has already happened. I assure you, these limitations were self-imposed. I insisted on them, without realizing that they would cause problems with generic code. I thought they would be good "lint" detection. https://issues.dlang.org/show_bug.cgi?id=3748 Problem is we could have other problems once we fix those. As you just showed, it has already happened. We should really do away with the cowboy style of designing language, which sadly Walter and I have been guilty of too often in the past. The slow but sure accretion of complexity of inout is a textbook example of where that leads. Andrei
Re: So what does (inout int = 0) do?
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even though
I thought it was being helpful when I suggested it). That is, functions
without inout parameters cannot declare local inout variables. But this
isn't really necessary, and should be fixed. I will discuss this in my
talk in a few weeks.
...
That's potentially dangerous. What about cases like the following?
void main(){
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a);
int[] z=foo(b);
}
Note, the =0 part isn't necessary right now, since it's not called. It's
just used to test if the function can compile.
In short, my opinion on inout is that it has some unnecessary
limitations, which can be removed, and inout will work as mostly
expected. These requirements to work around the limitations will go away.
...
Other important limitations of inout are e.g.:
- inout variables cannot be fields.
- There can be only one inout in scope.
I expect after reading this thread that the Q&A will be.. interesting.
-Steve
Re: So what does (inout int = 0) do?
On 4/15/16 3:28 PM, Andrei Alexandrescu wrote: On 4/15/16 2:39 PM, Steven Schveighoffer wrote: On 4/15/16 1:11 PM, Andrei Alexandrescu wrote: Would it be difficult to make it work without inout? T[] dup(T)(T[] arr) this should be doable. Problem is, you get identical instantiations for each of the different qualifiers, unless you take different actions based on the mutability. Instead: inout(T)[] dup(T)(inout(T)[] arr) This is one instantiation, no matter the mutability of the parameter. And it guarantees no molestation of arr, even if it's mutable. This would be much more difficult with a struct/class, whereas with inout it's pretty simple. But I think dup as it is defined is a bad example, because as defined by the language, it implies that you want a mutable version where the source may be const/immutable. In the general sense, a duplication function where you get the *same* mutability is more applicable for inout. A better support for this argument is std.array.replaceSlice at https://github.com/D-Programming-Language/phobos/blob/master/std/array.d#L2594: inout(T)[] replaceSlice(T)(inout(T)[] s, in T[] slice, in T[] replacement); So here we are guaranteed that (a) the result type is the same as the first argument, and (b) the first argument is never modified even if a mutable slice is passed. In fact, a mutable slice must be passed (slice is not marked as inout). I agree this is a nice property, and one that C++ does not enjoy. The questions are of course how important it is, how useful it is, and what price it is worth. Getting back to replaceSlice I'd define it in more flexible terms anyway. So I'd eliminate the use of inout there even if it did add value. You can add more flexibility and keep inout at the same time. The nice feature here is that inout protects the elements of s that aren't in slice, and there is no requirement to verify s and slice are the same underlying type, etc. One thing to understand is that inout is only valuable if you think const is valuable. That is, you think the advertisement of "no, I will not modify this parameter, give me whatever you got" is of value. If you don't care, then templates suffice. This is correct but incomplete. The omitted part is that inout is valuable when $EVERYTHING_YOU_SAID and also you want to transport the qualifier from an argument to the result. This diminishes its importance considerably for all folks, including those for whom const is important. Nope. Actually inout has proven to have a more interesting property of not requiring casting. void popFront(T)(inout(T)[] arr) void popFront(T)(ref inout(T)[] arr); (point stays) Yes, thanks, that is what I meant. This is possible only with inout. const will not cut it. The current definition is: void popFront(T)(T[] arr) which is OK, but there is no advertisement that popFront doesn't change any data in arr. Should this work as well? void popFront(ref const(T)[] arr); In other words conversion of ref T[] to ref const(T)[] is sound. No, because it's not sound. you cannot cast to const through 2+ indirections. However inout works there. I think the point of Kenji's argument is that inout's current limitations are what you are bumping into, and those limitations are unnecessary and arbitrary. We can make inout better and more consistent. Pretty easily actually. We can certainly fix the inout int = 0 problem. I'm not sure - at all in fact. This is at the tail of a sequence of changes of inout, and there is a history of such mini-designs leading to complications, regressions, and further mini-designs. It's the wolf that eats the dog that eats the cat that eats the mouse. We fix this and there's another and then another and then another. It has already happened. I assure you, these limitations were self-imposed. I insisted on them, without realizing that they would cause problems with generic code. I thought they would be good "lint" detection. https://issues.dlang.org/show_bug.cgi?id=3748 In fact Walter's and my design of inout is a prime example of the failings of that approach. We underdesigned it to work in a few small examples. We knew we lost when Kenji figured inout must be a type qualifier (we were hoping to getting away with it being a sort of a placeholder/wildcard). I think we should have pulled it back then. It's become a mini-monster that only wants more attention, more language changes, more work. It must be a type qualifier or it doesn't work. An interesting thing is that when you involve generic code, certain "good ideas" become very inconvenient. For example, this whole discussion is based on the idea that "if you don't have any inout parameters, why are you declaring inout variables? It makes no sense!" A very sensible and logical idea. But when you want code that works with or without inout variables, all of a sudden the same code is throwing an error in some cases because of an unforeseen situation. This is an
Re: So what does (inout int = 0) do?
On 15-Apr-2016 08:38, Andrei Alexandrescu wrote: On 04/15/2016 12:23 AM, Jonathan M Davis via Digitalmars-d wrote: On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d wrote: [snip] - Jonathan M Davis I think we should deprecate inout. For real. It costs way too much for what it does. For all I can tell most of D's proponents don't know how it works. -- Andrei Love this trend! inout is a monstrously complicated feature solving minor inconvenience. -- Dmitry Olshansky
Re: DMD internal: appendToModuleMember performance
On Friday, 15 April 2016 at 18:33:44 UTC, Johan Engelen wrote: Hi all, When building a unittest case in Weka.io's codebase, I measure that appendToModuleMember takes about 10% of the total compile time, and about 25% of total semantic analysis time. "appendToModuleMember" is the only function that pops up in profiling with such a large time fraction spent in it. Yep, see also: https://issues.dlang.org/show_bug.cgi?id=15323. When I tried to get rid of the ordered array, I ran into several interesting issues, but I don't remember many details. I'm thinking about removing the old array all-together. My question is: is it essential to keep an ordered list? (I see a `.shift(...)` call on the array, to put something in first position. If so, could that be solved by having *two* trees, where "in-order" iteration first iterates over the first one and then the second. The "high priority" symbols can then be put in the first tree, normal ones in the second tree (if that is how order matters...). Another "quick fix" if we have to keep the order would be to add a Bloom filter/… on the side to eliminate most array searches. — David
Re: So what does (inout int = 0) do?
On 4/15/16 2:39 PM, Steven Schveighoffer wrote: On 4/15/16 1:11 PM, Andrei Alexandrescu wrote: On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote: Didn't you use array.dup until now? It's a good example to handle qualifiers with inout. Would it be difficult to make it work without inout? T[] dup(T)(T[] arr) this should be doable. Problem is, you get identical instantiations for each of the different qualifiers, unless you take different actions based on the mutability. Instead: inout(T)[] dup(T)(inout(T)[] arr) This is one instantiation, no matter the mutability of the parameter. And it guarantees no molestation of arr, even if it's mutable. This would be much more difficult with a struct/class, whereas with inout it's pretty simple. But I think dup as it is defined is a bad example, because as defined by the language, it implies that you want a mutable version where the source may be const/immutable. In the general sense, a duplication function where you get the *same* mutability is more applicable for inout. A better support for this argument is std.array.replaceSlice at https://github.com/D-Programming-Language/phobos/blob/master/std/array.d#L2594: inout(T)[] replaceSlice(T)(inout(T)[] s, in T[] slice, in T[] replacement); So here we are guaranteed that (a) the result type is the same as the first argument, and (b) the first argument is never modified even if a mutable slice is passed. I agree this is a nice property, and one that C++ does not enjoy. The questions are of course how important it is, how useful it is, and what price it is worth. Getting back to replaceSlice I'd define it in more flexible terms anyway. So I'd eliminate the use of inout there even if it did add value. 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. What are a few examples of the power of inout? One thing to understand is that inout is only valuable if you think const is valuable. That is, you think the advertisement of "no, I will not modify this parameter, give me whatever you got" is of value. If you don't care, then templates suffice. This is correct but incomplete. The omitted part is that inout is valuable when $EVERYTHING_YOU_SAID and also you want to transport the qualifier from an argument to the result. This diminishes its importance considerably for all folks, including those for whom const is important. void popFront(T)(inout(T)[] arr) void popFront(T)(ref inout(T)[] arr); (point stays) This is possible only with inout. const will not cut it. The current definition is: void popFront(T)(T[] arr) which is OK, but there is no advertisement that popFront doesn't change any data in arr. Should this work as well? void popFront(ref const(T)[] arr); In other words conversion of ref T[] to ref const(T)[] is sound. What things does inout afford us, that would be otherwise not achievable? advertisement of const without having to cast the type to const (and all the limitations that entail). 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? The thing about @safe is it does enable things that otherwise would not be possible. Overall I agree there are plenty of things that deserve a revisit, but just putting in competition things against one another is unlikely to shed light on their technical merit. I think the point of Kenji's argument is that inout's current limitations are what you are bumping into, and those limitations are unnecessary and arbitrary. We can make inout better and more consistent. Pretty easily actually. We can certainly fix the inout int = 0 problem. I'm not sure - at all in fact. This is at the tail of a sequence of changes of inout, and there is a history of such mini-designs leading to complications, regressions, and further mini-designs. It's the wolf that eats the dog that eats the cat that eats the mouse. We fix this and there's another and then another and then another. It has already happened. In fact Walter's and my design of inout is a prime example of the failings of that approach. We underdesigned it to work in a few small examples. We knew we lost when Kenji figured inout must be a type qualifier (we were hoping to getting away with it being a sort of a placeholder/wildcard). I think we should have pulled it back then. It's become a mini-monster that only wants more attention, more language changes, more work. An interesting thing is that when you involve generic code, certain "good ideas" become very inconvenient. For example, this whole discussion is based on the idea that "if you don't have any inout parameters, why are you declaring inout variables? It makes no sense!" A very sensible and logica
Re: Opportunity: Software Execution Time Determinism
On Friday, 15 April 2016 at 04:01:16 UTC, Walter Bright wrote: Yeah, I'd like to see a proposal from Per who actually works in the field. Do you mean DIP? Are there anything else that's unclear about the needs of my company?
Re: Who wore it better?
On 4/15/16 2:48 PM, Andrei Alexandrescu wrote:
On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
import std.algorithm: min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Is that better or worse than the one without inout? -- Andrei
Better. It generates one implementation for all 9 combinations of
mutability. Yours generates 9 identical binary functions.
And yours possibly depends on a bug:
https://issues.dlang.org/show_bug.cgi?id=15930
-Steve
Re: Any usable SIMD implementation?
On Tuesday, 12 April 2016 at 10:55:18 UTC, xenon325 wrote: Have you seen how GCC's function multiversioning [1] ? I've been thinking about the gcc multiversioning since you mentioned it previously. I keep thinking about how the optimal algorithm for something like matrix multiplication depends on the size of the matrices. For instance, you might do something for very small matrices that just relies on one processor, then you add in SIMD as the size grows, then you add in multiple CPUs, then you add in the GPU (or maybe you add before CPUs), then you add in multiple computers. I don't know how some of those choices would get made at compile time for dynamic arrays. Would need some kind of run-time approach. At least for static arrays, you could do multiple versions of the function and then use template constraints to call whichever function. Some tuning would be necessary.
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 12:54:11 UTC, ixid wrote: On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu wrote: We want Phobos to be beautiful, a prime example of good D code. Admittedly, it also needs to be very general and efficient, which sometimes gets in the way. But we cannot afford an accumulation of mad tricks to obscure the large design. Andrei Why didn't we go with all functions being able to infer const, pure etc rather than just templates? The problem is essentially untractable when there are loops in the call graph. That being said, it would make sense to do it for auto functions.
Re: Who wore it better?
On 4/15/16 2:46 PM, Steven Schveighoffer wrote:
On 4/15/16 1:24 PM, Andrei Alexandrescu wrote:
I grepped phobos for "inout" and picked a heavy one. Not even cherry
picking here. You be the judges.
Before:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
alias U = inout(T);
static U* max(U* a, U* b) nothrow { return a > b ? a : b; }
static U* min(U* a, U* b) nothrow { return a < b ? a : b; }
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
After:
auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
if (is(typeof(r1.ptr < r2.ptr) == bool))
{
import std.algorithm : min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Who wore it better?
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
import std.algorithm: min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Is that better or worse than the one without inout? -- Andrei
Re: Who wore it better?
On 4/15/16 1:24 PM, Andrei Alexandrescu wrote:
I grepped phobos for "inout" and picked a heavy one. Not even cherry
picking here. You be the judges.
Before:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
alias U = inout(T);
static U* max(U* a, U* b) nothrow { return a > b ? a : b; }
static U* min(U* a, U* b) nothrow { return a < b ? a : b; }
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
After:
auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
if (is(typeof(r1.ptr < r2.ptr) == bool))
{
import std.algorithm : min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Who wore it better?
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
import std.algorithm: min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
-Steve
Re: So what does (inout int = 0) do?
On 4/15/16 1:11 PM, Andrei Alexandrescu wrote:
On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote:
Didn't you use array.dup until now? It's a good example to handle
qualifiers with inout.
Would it be difficult to make it work without inout?
T[] dup(T)(T[] arr)
this should be doable. Problem is, you get identical instantiations for
each of the different qualifiers, unless you take different actions
based on the mutability. Instead:
inout(T)[] dup(T)(inout(T)[] arr)
This is one instantiation, no matter the mutability of the parameter.
And it guarantees no molestation of arr, even if it's mutable.
This would be much more difficult with a struct/class, whereas with
inout it's pretty simple.
But I think dup as it is defined is a bad example, because as defined by
the language, it implies that you want a mutable version where the
source may be const/immutable. In the general sense, a duplication
function where you get the *same* mutability is more applicable for 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.
What are a few examples of the power of inout?
One thing to understand is that inout is only valuable if you think
const is valuable. That is, you think the advertisement of "no, I will
not modify this parameter, give me whatever you got" is of value. If you
don't care, then templates suffice.
void popFront(T)(inout(T)[] arr)
This is possible only with inout. const will not cut it. The current
definition is:
void popFront(T)(T[] arr)
which is OK, but there is no advertisement that popFront doesn't change
any data in arr.
What things does inout afford us, that would be otherwise not achievable?
advertisement of const without having to cast the type to const (and all
the limitations that entail).
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?
The thing about @safe is it does enable things that otherwise would not
be possible. Overall I agree there are plenty of things that deserve a
revisit, but just putting in competition things against one another is
unlikely to shed light on their technical merit.
I think the point of Kenji's argument is that inout's current
limitations are what you are bumping into, and those limitations are
unnecessary and arbitrary. We can make inout better and more consistent.
Pretty easily actually. We can certainly fix the inout int = 0 problem.
To restate my arguments:
1. The motivation of inout is clear and simple - have it as a
placeholder for any other qualifier so as to avoid the method
duplication observed in C++. However, it has over time grown into a
feature of which complexity way transcends its small usefulness.
It has some rough edges. These can be smoothed out.
2. Attempting to make inout useful have created their own problems,
solving which in turn have increased its complexity. This cycle of
accretions has led over time to a vortex of oddity in the middle of the
type system.
This is not what you are railing against. The current limitations (and
their workarounds) are self-imposed, we just need to get rid of them.
An interesting thing is that when you involve generic code, certain
"good ideas" become very inconvenient. For example, this whole
discussion is based on the idea that "if you don't have any inout
parameters, why are you declaring inout variables? It makes no sense!" A
very sensible and logical idea. But when you want code that works with
or without inout variables, all of a sudden the same code is throwing an
error in some cases because of an unforeseen situation.
Another example is code like this:
int firstInt(T...)(T t)
{
foreach(ref x; t)
{
static if(typeof(x) == int)
return x;
}
return -1;
}
This throws an error because if there is an int in T..., then return -1
statement is "unreachable". This is similar to the inout int = 0 case.
In non-generic code, it makes sense to flag code that won't be reached.
But in generic code, it's actually not a true statement for all
instantiations of the template! It's another limitation we should relax.
3. For all problems that inout is purported to solve, I know of idioms
that are definitely simpler and overall almost as good if not better. So
a hard question is whether the existence is justified.
I know of no "better" idioms, in terms of code generation and
specificity, to replace inout (or at least, inout as I envision it
should be). Care to elaborate?
-Steve
DMD internal: appendToModuleMember performance
Hi all, When building a unittest case in Weka.io's codebase, I measure that appendToModuleMember takes about 10% of the total compile time, and about 25% of total semantic analysis time. "appendToModuleMember" is the only function that pops up in profiling with such a large time fraction spent in it. The culprit is the linear search at the end of appendToModuleMember, because the members list with Dsymbols gets pretty large (50k+ members). https://github.com/D-Programming-Language/dmd/blob/master/src/dtemplate.d#L8012-L8026 I've modified the code to also store the list of members as an rbtree, and voila, much faster compiles: from 26sec to 20sec (semantic only). The old data structure is still there and the only change is to do a lookup into the tree instead of the linear search. The hack is here: https://github.com/ldc-developers/ldc/compare/master...JohanEngelen:speed_up I couldn't use symtab as it isn't populated with all symbols and I wasn't sure if it would break things. I'm thinking about removing the old array all-together. My question is: is it essential to keep an ordered list? (I see a `.shift(...)` call on the array, to put something in first position. If so, could that be solved by having *two* trees, where "in-order" iteration first iterates over the first one and then the second. The "high priority" symbols can then be put in the first tree, normal ones in the second tree (if that is how order matters...). Thanks, Johan
Re: So what does (inout int = 0) do?
On 04/15/2016 02:24 PM, jmh530 wrote: I had not realized that the main reason that inout was added was because of not being able to use templates as virtual functions in classes. The main reason is actually avoiding code duplication is such situations (i.e. the problem has a solution just not ideal). -- Andrei
Dead link finding automation
Can we automate stuff like https://issues.dlang.org/show_bug.cgi?id=15929? There are quite a few tools around, not to mention we could easily roll our own. Who'd like to take this project? Thx! -- Andrei
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 17:11:39 UTC, Andrei Alexandrescu wrote: 3. For all problems that inout is purported to solve, I know of idioms that are definitely simpler and overall almost as good if not better. So a hard question is whether the existence is justified. If it's something to be avoided except in particular cases, then I suggest that is made clear in the documentation. I had not realized that the main reason that inout was added was because of not being able to use templates as virtual functions in classes.
move has{Mobile,Swappable}Elements and move{Front,Back,At} to std.algorithm.mutation
Hi all, since this has been pending for more than one week without a lot of interest and it's a larger deprecation, I thought I try to ping people here. #4170 [1] is a proposal to move moveAt, moveFront and moveBack to std.algorithm.mutation. It also moves the two templates hasMobileElements and hasSwappableElements. The reasoning is that std.algorithm.mutation "contains generic mutation algorithms" and already has move, moveAll, moveSome, swap, swapRanges. Since #4127 [2] swapAt is there too (=publicly documented) The template hasSwappableElements already only calls swap from std.algorithm.mutation. You can find more details at [1]. The current deprecation time is two years, which imho is a bit long, but I haven't heard a word from any maintainer on Phobos's current deprecation policy. [1] https://github.com/D-Programming-Language/phobos/pull/4170 [2] https://github.com/D-Programming-Language/phobos/pull/4127
chain should stop chaining at the first infinite range
https://issues.dlang.org/show_bug.cgi?id=15928 Destroy! -- Andrei
Re: Any usable SIMD implementation?
On Sunday, 3 April 2016 at 07:39:00 UTC, Manu wrote: On 3 April 2016 at 16:14, 9il via Digitalmars-d wrote: Is it possible to introduce compile time information about target platform? I am working on BLAS from scratch implementation. And it is no hope to create something useable without CT information about target. Best regards, Ilya My SIMD implementation has been blocked on that for years too. I need to know the SIMD level flags passed to the compiler at least, and DMD needs to introduce the concept. https://github.com/ldc-developers/ldc/pull/1434
Re: Who wore it better?
On 04/15/2016 01:31 PM, Namespace wrote: Since it is a template: Why these attributes: @trusted pure nothrow ? @trusted is not inferrable, the others are type-independent and nice for the documentation. -- Andrei
Re: Who wore it better?
Since it is a template: Why these attributes: @trusted pure nothrow ?
Re: Who wore it better?
https://github.com/D-Programming-Language/phobos/pull/4201 -- Andrei
Who wore it better?
I grepped phobos for "inout" and picked a heavy one. Not even cherry
picking here. You be the judges.
Before:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted pure nothrow
{
alias U = inout(T);
static U* max(U* a, U* b) nothrow { return a > b ? a : b; }
static U* min(U* a, U* b) nothrow { return a < b ? a : b; }
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
After:
auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow
if (is(typeof(r1.ptr < r2.ptr) == bool))
{
import std.algorithm : min, max;
auto b = max(r1.ptr, r2.ptr);
auto e = min(r1.ptr + r1.length, r2.ptr + r2.length);
return b < e ? b[0 .. e - b] : null;
}
Who wore it better?
Andrei
Can std.conv.toImpl please be deprecated
Before I opened a PR, I wanted to get some second opinions. There is no reason IMO that the various overloads of toImpl should be public. Having the internal functionality of a parent function, in this case to, be exposed like this causes: 1. The docs to be cluttered with useless info. Anything pertinent can be moved to the to docs. 2. The function cannot be refactored because its guts are shown to the world Also, there is no reason that anyone should use toImpl over to. So can I please mark toImpl as deprecated in order to clean up std.conv?
Re: So what does (inout int = 0) do?
On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote: Didn't you use array.dup until now? It's a good example to handle qualifiers with inout. Would it be difficult to make it work without 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. What are a few examples of the power of inout? What things does inout afford us, that would be otherwise not achievable? 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? The thing about @safe is it does enable things that otherwise would not be possible. Overall I agree there are plenty of things that deserve a revisit, but just putting in competition things against one another is unlikely to shed light on their technical merit. I just cannot agree your argument. I understand and would like to be better informed. So could you please substantiate your argument by replying to the questions above? To restate my arguments: 1. The motivation of inout is clear and simple - have it as a placeholder for any other qualifier so as to avoid the method duplication observed in C++. However, it has over time grown into a feature of which complexity way transcends its small usefulness. 2. Attempting to make inout useful have created their own problems, solving which in turn have increased its complexity. This cycle of accretions has led over time to a vortex of oddity in the middle of the type system. 3. For all problems that inout is purported to solve, I know of idioms that are definitely simpler and overall almost as good if not better. So a hard question is whether the existence is justified. There are 306 uses of inout in Phobos. A good thing to do would be an investigation of their usefulness. Andrei
Re: So what does (inout int = 0) do?
2016-04-15 22:41 GMT+09:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>: > 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
We need a couple hundreds of these
https://github.com/D-Programming-Language/phobos/pull/4200 -- Andrei
Re: So what does (inout int = 0) do?
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote: Consider: https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152 It works around a limitation of inout that isn't necessary (even though I thought it was being helpful when I suggested it). That is, functions without inout parameters cannot declare local inout variables. But this isn't really necessary, and should be fixed. I will discuss this in my talk in a few weeks. Note, the =0 part isn't necessary right now, since it's not called. It's just used to test if the function can compile. In short, my opinion on inout is that it has some unnecessary limitations, which can be removed, and inout will work as mostly expected. These requirements to work around the limitations will go away. I expect after reading this thread that the Q&A will be.. interesting. -Steve
Re: Where to buy the official DLang shirt?
On 4/15/16 7:59 AM, Andre wrote: Hi, Is there an official DLang shirt, i can buy? I work in a software company and would like to make some advertisement for D. The profit for marketing articles like the shirt e.g. could be used for the DLang foundation. This would be a nice way to donate some money. Kind regards Andre AFAIK, there isn't one. If you have been to one of the past 3 conferences (except last year's), there was a shirt you got. Or if you contributed to the original kickstarter campaign, you would have gotten a shirt. But these are dconf shirts, not dlang. Ian was sporting a pretty good D shirt that he custom made in the first dconf :) Dlang swag in general should be done for d foundation IMO. -Steve
Re: sparsehash
On Friday, 15 April 2016 at 14:53:49 UTC, Elias Peterson wrote: There is this for D: http://code.dlang.org/packages/judy Thanks.
Re: sparsehash
On Friday, 15 April 2016 at 13:55:33 UTC, Nordlöw wrote: On Friday, 15 April 2016 at 11:42:09 UTC, Nordlöw wrote: http://goog-sparsehash.sourceforge.net/ https://github.com/sparsehash/sparsehash Further, a Judy array seem like another interesting container I would like to get implemented in D: http://judy.sourceforge.net/index.html http://judy.sourceforge.net/doc/10minutes.htm http://judy.sourceforge.net/application/shop_interm.pdf There is this for D: http://code.dlang.org/packages/judy
Re: sparsehash
On Friday, 15 April 2016 at 13:55:33 UTC, Nordlöw wrote: On Friday, 15 April 2016 at 11:42:09 UTC, Nordlöw wrote: http://goog-sparsehash.sourceforge.net/ https://github.com/sparsehash/sparsehash Further, a Judy array seem like another interesting container I would like to get implemented in D: http://judy.sourceforge.net/index.html http://judy.sourceforge.net/doc/10minutes.htm http://judy.sourceforge.net/application/shop_interm.pdf I'm in great need of a more space-efficient alternative to D's builtin associative arrays to lower the memory usage in my D knowledge database.
Re: sparsehash
On Friday, 15 April 2016 at 11:42:09 UTC, Nordlöw wrote: http://goog-sparsehash.sourceforge.net/ https://github.com/sparsehash/sparsehash Further, a Judy array seem like another interesting container I would like to get implemented in D: http://judy.sourceforge.net/index.html http://judy.sourceforge.net/doc/10minutes.htm http://judy.sourceforge.net/application/shop_interm.pdf
Re: So what does (inout int = 0) do?
On 04/15/2016 02:15 AM, Vladimir Panteleev wrote: On Friday, 15 April 2016 at 05:38:56 UTC, Andrei Alexandrescu wrote: I think we should deprecate inout. For real. It costs way too much for what it does. For all I can tell most of D's proponents don't know how it works. -- Andrei What would replace it in the case of classes, where you can't have templated virtual methods? Perhaps a mechanism to declare a templated virtual function, and a list of instantiations which will go into the vtable? You write several one-liners that forward to an internal template implementation. If we are to kill inout and replace it with something else, then it should support cases where inout failed, such as inout on the parameter of a delegate passed to the function (see: inout opApply). I think we should kill it, period. No replacement is really needed, for the most part most problems with inout are complications caused by the very presence of inout. C++ has no parameterization of qualifiers and lived with it like a guy lives with a bald spot on a butt cheek. There's not even a proposal I can remember to fix that. Those duplications are the least of C++'s, or any langauge's, problems. inout must go. Andrei
Re: the d.chm miss some modules in Standard Library section
On Friday, 15 April 2016 at 06:53:29 UTC, lotusdeng wrote: in windows, many modules like core.sys.windows.windows not included in d.chm's Standard Library, this is not convenience for primer, the d.chm should contain it. core.sys.windows.windows is not documented because it is supposed to be a direct mapping of Windows C platform headers (`import core.sys.windows.X` == `#include `). For documentation on that, refer to MSDN.
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 12:54:11 UTC, ixid wrote: Why didn't we go with all functions being able to infer const, pure etc rather than just templates? Non-templated function may not have their source code available. For consistency, non-template function have no inference.
Re: So what does (inout int = 0) do?
On 04/15/2016 02:40 AM, Shammah Chancellor wrote: I think that behavioral type checks are common enough in D that it should have it's own first-class syntax. No. -- Andrei
Re: So what does (inout int = 0) do?
On 04/15/2016 02:49 AM, Walter Bright wrote: On 4/14/2016 8:10 PM, Andrei Alexandrescu wrote: Commenting it out yields a number of unittest compilation errors, neither informative about the root of the problem and indicative as to how the parameter solves it. https://issues.dlang.org/show_bug.cgi?id=15926 Nice, thanks. I think I can put a finger on what bothers me the most: adding that "inout int = 0" to make code work cannot be an acceptable solution to any problem. So the fact that the problem exists is the actual problem. It's basic sense and sensibility in engineering. -- Andrei
Re: So what does (inout int = 0) do?
On 04/15/2016 03:42 AM, deadalnix wrote: On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote: IIRC, the problem has to do with ranges of inout elements working correctly, which gets really funky, because inout is a temporary thing and not a full-on type constructor/qualifier. I believe that Kenji is the one that implemented the fix, and I think that he explained it in the newsgroup at some point. Certainly, there have been a few times that it's come up in D.Learn when folks ask what the heck it is, so there should be a few posts floating around with an explanation. This is the only useful post that I could find in a quick search though: Whatever the problem is, none of this seems like a good solution. I agree. -- Andrei
Re: So what does (inout int = 0) do?
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. Andrei
Re: So what does (inout int = 0) do?
On 04/15/2016 05:07 AM, Timon Gehr wrote: The fundamental problem is that inout is disallows certain kinds of composition. It's a flawed language primitive. I agree. The more I try things with it the more awfully complex and useless it is. inout must go. -- Andrei
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 09:07:27 UTC, Timon Gehr wrote: Related: Phobos should never use is(typeof(...)). Contrary to popular belief, is(typeof(...)) is not the same as __traits(compiles,...). I don't think it should be using __traits(compiles) either. I'd prefer to see built from the other reflection primitives... though I'll grant that compiles is flexible. hasMember!(Range, "empty") isn't as specific as the current test... and is(typeof(Range.init.empty) : bool) isn't as flexible (I don't think that takes an empty that returns an opCast:bool item) But regardless, I still kinda prefer the idea of building these reflection helper functions so they do cover the cases nicely... then a helper function that takes a list of conditions and tells you which one failed... hmm, this is getting interesting.
Re: So what does (inout int = 0) do?
On 4/15/16 8:59 AM, Nick Treleaven wrote:
On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
Certainly, there have been a few times that it's come up in D.Learn
when folks ask what the heck it is, so there should be a few posts
floating around with an explanation. This is the only useful post that
I could find in a quick search though:
http://forum.dlang.org/post/mh68p8$2p56$1...@digitalmars.com
He says:
Alternatively, you could have the lambda take an R as a parameter. Or
fix the semantics ...
Assuming it works OK, that seems much cleaner:
(R r)
{
if (r.empty) {}
...
}
That makes other unittests fail (those with noncopyable ranges).
Overall we really need to spend some time on making Phobos simpler and
better. The mishmash of styles and variable quality of contributions has
slowly been gnawing at the sheer quality of the code.
Andrei
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
Certainly, there have been a few times that it's come up in
D.Learn when folks ask what the heck it is, so there should be
a few posts floating around with an explanation. This is the
only useful post that I could find in a quick search though:
http://forum.dlang.org/post/mh68p8$2p56$1...@digitalmars.com
He says:
Alternatively, you could have the lambda take an R as a
parameter. Or fix the semantics ...
Assuming it works OK, that seems much cleaner:
(R r)
{
if (r.empty) {}
...
}
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu wrote: Consider: https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152 There is no explanation to it in the source code, and the line blames to https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant). I've been wondering what that is myself, so I've just cargo-cult-copied it into my code. Thanks for the post.
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu wrote: We want Phobos to be beautiful, a prime example of good D code. Admittedly, it also needs to be very general and efficient, which sometimes gets in the way. But we cannot afford an accumulation of mad tricks to obscure the large design. Andrei Why didn't we go with all functions being able to infer const, pure etc rather than just templates?
Re: Where to buy the official DLang shirt?
On Friday, 15 April 2016 at 11:59:55 UTC, Andre wrote: Hi, Is there an official DLang shirt, i can buy? I work in a software company and would like to make some advertisement for D. The profit for marketing articles like the shirt e.g. could be used for the DLang foundation. This would be a nice way to donate some money. Kind regards Andre Dlang shirt? I would definitely buy one too! Please make it happen guys!
Where to buy the official DLang shirt?
Hi, Is there an official DLang shirt, i can buy? I work in a software company and would like to make some advertisement for D. The profit for marketing articles like the shirt e.g. could be used for the DLang foundation. This would be a nice way to donate some money. Kind regards Andre
sparsehash
Have anybody converted Google's sparsehash to D? See: http://goog-sparsehash.sourceforge.net/ https://github.com/sparsehash/sparsehash
Re: So what does (inout int = 0) do?
2016-04-15 14:38 GMT+09:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>: > On 04/15/2016 12:23 AM, Jonathan M Davis via Digitalmars-d wrote: > >> On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d >> wrote: >> >>> Consider: >>> >>> >>> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi >>> tives.d#L152 >>> >>> There is no explanation to it in the source code, and the line blames to >>> https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant). >>> >>> Commenting it out yields a number of unittest compilation errors, >>> neither informative about the root of the problem and indicative as to >>> how the parameter solves it. >>> >>> There are two issues here: >>> >>> 1. Once a problem/solution pair of this degree of subtlety crops up, we >>> need to convince ourselves that that's sensible. If we deem it not so, >>> we look into improving the language to make the problem disappear. >>> >>> 2. There needs to be documentation for people working on the standard >>> library so they don't need to waste time on their own discovery process. >>> >>> We want Phobos to be beautiful, a prime example of good D code. >>> Admittedly, it also needs to be very general and efficient, which >>> sometimes gets in the way. But we cannot afford an accumulation of mad >>> tricks to obscure the large design. >>> >> >> IIRC, the problem has to do with ranges of inout elements working >> correctly, >> which gets really funky, because inout is a temporary thing and not a >> full-on type constructor/qualifier. I believe that Kenji is the one that >> implemented the fix, and I think that he explained it in the newsgroup at >> some point. Certainly, there have been a few times that it's come up in >> D.Learn when folks ask what the heck it is, so there should be a few posts >> floating around with an explanation. This is the only useful post that I >> could find in a quick search though: >> >> http://forum.dlang.org/post/mh68p8$2p56$1...@digitalmars.com >> >> inout attempts to solve a very real problem, but it does seem to be >> surprisingly hard to understand and use prooperly even though it's >> theoretically simple. And this bit with ranges is a quirk that I think >> very >> few people understand and remember. I usually forget exactly what it does >> when it comes up and have to try and dig through the newsgroup archives >> for >> a previous discussion on it. >> >> - Jonathan M Davis >> > > I think we should deprecate inout. For real. It costs way too much for > what it does. For all I can tell most of D's proponents don't know how it > works. -- Andrei > 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 Kenji Hara
Re: So what does (inout int = 0) do?
On 15.04.2016 11:07, Timon Gehr wrote: ... Most of Phobos code assumes that ranges be struct fields. Most of Phobos assumes that ranges can be The fundamental problem is that inout is disallows certain kinds of composition. ... inout disallows
Re: So what does (inout int = 0) do?
On 15.04.2016 05:10, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
...
Related: Phobos should never use is(typeof(...)). Contrary to popular
belief, is(typeof(...)) is not the same as __traits(compiles,...).
void main(){
int x;
static void foo(){
static assert(is(typeof({return x;})));
static assert(!__traits(compiles,{return x;}));
}
}
typeof suspends context access checks. This is almost never what you
want when checking for compilability.
There is no explanation to it in the source code, and the line blames to
https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).
Commenting it out yields a number of unittest compilation errors,
neither informative about the root of the problem and indicative as to
how the parameter solves it.
There are two issues here:
1. Once a problem/solution pair of this degree of subtlety crops up, we
need to convince ourselves that that's sensible. If we deem it not so,
we look into improving the language to make the problem disappear.
...
Declaring variables with inout in their type is only allowed for stack
variables in functions that have inout parameters. The (inout int) trick
attempts to allow such types to be ranges.
It is not even a correct fix: Most of Phobos code assumes that ranges
be struct fields. The following code causes a compilation failure in the
guts of std.algorithm:
inout(int)[] foo(inout(int)[] x){
static assert(isInputRange!(typeof(x)));
return x.map!(x=>x).array;
}
What good is an "InputRange" that does not support map?
The fundamental problem is that inout is disallows certain kinds of
composition. It's a flawed language primitive. The way to fix this is to
have parametric polymorphism in the language.
Re: Opportunity: Software Execution Time Determinism
On Wednesday, 13 April 2016 at 22:25:12 UTC, Nick B wrote: What is absolute time-determinism in a CPU architectures ? Take the expression "absolute time-determinism" with a grain of salt. I'm saying that eventhough the machine code doesn't contain any branches and caches have been invalidated prior to the start of each frame, the execution time of the program may still contain variations that depend on the *values* being inputted into the calculation. The reason for this is that, on some CPU-architectures, some instructions such as trigonometric functions are implemented using microcode that requires different amount of clock-cycles depending on the parameter(s) set to them. At my work, these variations have actually been measured and documented and are used to calculate worst-variations of WCET. A compiler backend, such as DMDs, could be enhanced to leverage these variations automatically.
Re: So what does (inout int = 0) do?
On Friday, 15 April 2016 at 05:38:56 UTC, Andrei Alexandrescu wrote: I think we should deprecate inout. For real. It costs way too much for what it does. For all I can tell most of D's proponents don't know how it works. -- Andrei This is the explanation I came up with, not sure if accurate. And only to teach myself the basics. https://p0nce.github.io/d-idioms/#Knowing-inout-inside-out I'm all for removing things!
