Re: Contradictory justification for status quo
On Mon, 02 Mar 2015 00:48:54 +, Zach the Mystic wrote: > I don't think anybody disagrees with this. Kenji's a miracle. he's like Chuck Norris, only better. ;-) signature.asc Description: PGP signature
Re: Contradictory justification for status quo
On Sunday, 1 March 2015 at 11:30:52 UTC, bearophile wrote: Walter Bright: Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. But my point was that probably there are even better things that Kenji can do in part of the time he works on D. I think this once again brings up the issue of what might be called "The Experimental Space" (for which std.experimental is the only official acknowledgment thus far). Simply put, there are things which it would be nice to try out, which can be conditionally pre-approved depending on how they work in real life. There are a lot of things which would be great to have, if only some field testing could verify that they aren't laden with show-stopping flaws. But these represent a whole "middle ground" between pre-approved, and rejected. The middle ground is fraught with tradeoffs -- most prominently that if the field testers find the code useful it becomes the de facto standard *even if* fatal flaws are discovered in the design. Yet if you tell people honestly, "this may not be the final design," a lot fewer people will be willing to test it. The Experimental Space must have a whole different philosophy about what it is -- the promises you make, or more accurately don't make, and the courage you have to reject a bad design even when it is already being used in real-world code. Basically, the experimental space must claim "tentatively approved for D, pending field testing" -- and it must courageously stick to that claim. That might give Kenji the motivation to implement some interesting new approaches to old problems, knowing that even if in the final analysis they fail, they will at least get a chance to prove themselves first. (Maybe there aren't really that many candidates for this approach anyway, but I thought the idea should be articulated at least.)
Re: Contradictory justification for status quo
On Saturday, 28 February 2015 at 23:03:23 UTC, Walter Bright wrote: On 2/28/2015 2:31 AM, bearophile wrote: Zach the Mystic: You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I agree that probably there are often better ways to use Kenji time for the development of D. Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. I don't think anybody disagrees with this. Kenji's a miracle.
Re: Contradictory justification for status quo
On Saturday, 28 February 2015 at 21:11:54 UTC, Andrei Alexandrescu wrote: On 2/28/15 12:20 PM, Sativa wrote: I'm curious if project management(e.g., MS Project) is used to optimize and clarify goals for the D language? I've pushed for trello for a good while, it didn't catch up. -- Andrei Note that most never had any access to it.
Re: Contradictory justification for status quo
Walter Bright: Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. But my point was that probably there are even better things that Kenji can do in part of the time he works on D. Bye, bearophile
Re: Contradictory justification for status quo
On 2015-02-28 22:11, Andrei Alexandrescu wrote: I've pushed for trello for a good while, it didn't catch up. -- Andrei There's something called HuBoard [1], project management for Github issues. I haven't used it myself but might be worth taking a look at. Although it looks like you need the issues in Github, we only have pull requests. [1] https://huboard.com/ -- /Jacob Carlborg
Re: Contradictory justification for status quo
On 2/28/2015 2:31 AM, bearophile wrote: Zach the Mystic: You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I agree that probably there are often better ways to use Kenji time for the development of D. Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community.
Re: Contradictory justification for status quo
On 2/27/2015 2:42 AM, Dominikus Dittes Scherkl wrote: How can we make progress, Look at the changelog, there's tremendous progress.
Re: Contradictory justification for status quo
On Saturday, 28 February 2015 at 21:11:54 UTC, Andrei Alexandrescu wrote: On 2/28/15 12:20 PM, Sativa wrote: I'm curious if project management(e.g., MS Project) is used to optimize and clarify goals for the D language? I've pushed for trello for a good while, it didn't catch up. -- Andrei Trello would be nice, it even has a good feature request/voting system IIRC.
Re: Contradictory justification for status quo
On 2/28/15 12:20 PM, Sativa wrote: I'm curious if project management(e.g., MS Project) is used to optimize and clarify goals for the D language? I've pushed for trello for a good while, it didn't catch up. -- Andrei
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote: On 2/26/15 6:17 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Feb 26, 2015 at 05:57:53PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/26/15 5:48 PM, Zach the Mystic wrote: I sometimes feel so bad for Kenji, who has come up with several reasonable solutions for longstanding problems, *and* implemented them, only to have them be frozen for *years* by indecision at the top. Yah, we need to be quicker with making decisions, even negative. This requires collaboration from both sides - people shouldn't get furious if their proposal is rejected. Kenji has been incredibly gracious about this. [...] I don't think people would be furious if they knew from the beginning that something would be rejected. At least, most reasonable people won't, and I'm assuming that the set of unreasonable people who contribute major features is rather small (i.e., near cardinality 0). Well yes in theory there's no difference between theory and practice etc. What has happened historically (fortunately not as much lately) was that statistically most proposals have been simply Not Good. Statistically, proposal authors have been Positively Convinced that their proposals were of Obviously Excellent. (That includes me; statistically most ideas I've ever had have been utter crap, but seldom seemed like it in the beginning.) This cycle has happened numerous times. We've handled that poorly in the past, and we're working on handling it better. What *does* make people furious / disillusioned is when they are led to believe that their work would be accepted, and then after they put in all the effort to implement it, make it mergeable, keep it up to date with the moving target of git HEAD, etc., it then gets summarily dismissed. Or ignored for months and years, and then suddenly shot down. Or worse, get *merged*, only to be reverted later because the people who didn't bother giving feedback earlier now show up and decide that they don't like the idea after all. (It's a different story if post-merge rejection happened because it failed in practice -- I think reasonable people would accept that. But post-merge rejection because of earlier indecision / silence kills morale really quickly. Don't expect to attract major contributors if morale is low.) Yes, getting back on a decision or promise is a failure of leadership. For example, what happened with [$] was regrettable. We will do our best to avoid such in the future. I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it. What I hope will NOT happen is that people come to me with a mediocre proposal going, "We've put a lot of Work into this. Well?" Andrei I'm curious if project management(e.g., MS Project) is used to optimize and clarify goals for the D language? If such a project was maintained, anyone could download it and see the current state of D. The main use being the optimization of tasks and display the "timeline". If something has been sitting around for a year and is blocking other tasks then you can easily see that. It obviously would lot of work to setup such a project. I imagine you could write some script to import data from github or whatever into the project and possibly vice versa.
Re: Contradictory justification for status quo
On 2/27/2015 7:33 AM, H. S. Teoh via Digitalmars-d wrote: @safe has some pretty nasty holes right now... like: https://issues.dlang.org/show_bug.cgi?id=5270 https://issues.dlang.org/show_bug.cgi?id=8838 https://issues.dlang.org/show_bug.cgi?id=12822 https://issues.dlang.org/show_bug.cgi?id=13442 https://issues.dlang.org/show_bug.cgi?id=13534 https://issues.dlang.org/show_bug.cgi?id=13536 https://issues.dlang.org/show_bug.cgi?id=13537 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14138 None of those are a big deal (i.e. fundamental), and are certainly not a justification for throwing the whole thing out and starting over. Some of them aren't even in the core language, but in incorrect usage of @trusted in Phobos. Just fix them.
Re: Contradictory justification for status quo
On 2/28/15 7:53 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: On Friday, 27 February 2015 at 21:19:31 UTC, Andrei Alexandrescu wrote: On 2/27/15 1:07 PM, H. S. Teoh via Digitalmars-d wrote: What about this, if we're serious about @safe actually*guaranteeing* anything: after 2.067 is released, we reimplement @safe by making it reject every language construct by default. I don't think this is practical. It's a huge amount of work over a long time. That's easy enough to solve, though. I figure there are ways to go about it. I just don't find it practical. It might have been a good idea eight years ago. -- Andrei
Re: Contradictory justification for status quo
On Saturday, 28 February 2015 at 10:40:32 UTC, bearophile wrote: Andrei Alexandrescu: I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it. The second scope proposal looks simpler than the first: http://wiki.dlang.org/User:Schuetzm/scope2 Still working on it, but I think we're on the right track. Zach had some really good ideas. Later in Rust they have added some lifetime inference to reduce the annotation burden in many cases. I just modified Walter's RCArray to work with the new proposal. It looks almost identical, but now supports safe slicing. (It currently lacks a way to actually get an RCArray of a slice, but that can be added as an `alias this`). There's only one `scope` annotation in the entire code. Even though the proposal includes a `return` annotation, it's not needed in this case. In general, if it works out like I imagine, there will be almost no annotations. They will only ever be necessary for function signatures, and then only in `@system` code, `extern`/`export` declarations, and occasionally for `@safe` functions. Everything else will just work. (@safe will become slightly stricter, but that's a good thing.)
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 21:19:31 UTC, Andrei Alexandrescu wrote: On 2/27/15 1:07 PM, H. S. Teoh via Digitalmars-d wrote: What about this, if we're serious about @safe actually*guaranteeing* anything: after 2.067 is released, we reimplement @safe by making it reject every language construct by default. I don't think this is practical. It's a huge amount of work over a long time. That's easy enough to solve, though. The new behaviour can at first be opt-in, enabled by a command-line flag (like we already do with -dip25). We have an entire release cycle, or longer if we need that, to get at least Phobos and druntime to compile. Once that is done, people can test their own code with it, and it can be enabled on the auto-tester by default. When some time has passed, we invert the switch - it's then opt-out. People can still disable it if they just want to get their code to compile without fixing it (or reporting a bug if it's our fault). Finally, the old behaviour can be removed altogether. Besides, even with that approach there's still no guarantee; implementation bugs are always possible in either approach. As H.S. Teoh said, these can be detected by git bisect. I think the closest thing to what you're after is progress and preservation proofs on top of a core subset of the language. It would be great if somebody wanted to do this. Wouldn't that effectively mean introducing another kind of `@safe`, that only allows to use said core subset? Or a compiler switch? How else would it be practicable?
Re: Contradictory justification for status quo
Andrei Alexandrescu: I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it. The second scope proposal looks simpler than the first: http://wiki.dlang.org/User:Schuetzm/scope2 Later in Rust they have added some lifetime inference to reduce the annotation burden in many cases. Bye, bearophile
Re: Contradictory justification for status quo
Zach the Mystic: You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I agree that probably there are often better ways to use Kenji time for the development of D. Bye, bearophile
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 21:09:51 UTC, H. S. Teoh wrote: >https://issues.dlang.org/show_bug.cgi?id=12822 >https://issues.dlang.org/show_bug.cgi?id=13442 >https://issues.dlang.org/show_bug.cgi?id=13534 >https://issues.dlang.org/show_bug.cgi?id=13536 >https://issues.dlang.org/show_bug.cgi?id=13537 >https://issues.dlang.org/show_bug.cgi?id=14136 >https://issues.dlang.org/show_bug.cgi?id=14138 > >There are probably other holes that we haven't discovered yet. I wanted to say that besides the first two bugs I tried to address, none of the rest in your list involves more than just telling the compiler to check for this or that, whatever the case may be, per bug. Maybe blanket use of `@trusted` to bypass an over-cautious compiler is the only real danger I personally am able to worry about. I simplified my thinking by dividing everything into "in function" and "outside of function". So I ask, within a function, what do I need to know to ensure everything is safe? And then, from outside a function, what do I need to know to ensure everything is safe? The function has inputs and outputs, sources and destinations.
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 21:09:51 UTC, H. S. Teoh wrote: No, what I meant was that in an "assume safe unless proven otherwise" system, there's bound to be holes because the combinatorial explosion of feature combinations makes it almost certain there's *some* unsafe combination we haven't thought of yet that the compiler currently accepts. And it may be a long time before we discover this flaw. To be back to the original problem, there are various instances of: - A is safe and useful in safe code, let's not making it unsafe ! - B is safe and useful in safe code, let's not making it unsafe ! Yet A and B may be unsafe used together, so one of them should be made unsafe. You ends up in the same situation than exposed in the first post.
Re: Contradictory justification for status quo
On 2/27/15 1:07 PM, H. S. Teoh via Digitalmars-d wrote: What about this, if we're serious about @safe actually*guaranteeing* anything: after 2.067 is released, we reimplement @safe by making it reject every language construct by default. I don't think this is practical. It's a huge amount of work over a long time. Besides, even with that approach there's still no guarantee; implementation bugs are always possible in either approach. I think the closest thing to what you're after is progress and preservation proofs on top of a core subset of the language. It would be great if somebody wanted to do this. Andrei
Re: Contradictory justification for status quo
On Fri, Feb 27, 2015 at 07:57:22AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 2/27/15 7:33 AM, H. S. Teoh via Digitalmars-d wrote: > >On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via > >Digitalmars-d wrote: > >[...] > >>Safety is good to have, and the simple litmus test is if you slap > >>@safe: at the top of all modules and you use no @trusted (or of course > >>use it correctly), you should have memory safety, guaranteed. > >[...] > > > >@safe has some pretty nasty holes right now... like: > > > > https://issues.dlang.org/show_bug.cgi?id=5270 > > https://issues.dlang.org/show_bug.cgi?id=8838 > > https://issues.dlang.org/show_bug.cgi?id=12822 > > https://issues.dlang.org/show_bug.cgi?id=13442 > > https://issues.dlang.org/show_bug.cgi?id=13534 > > https://issues.dlang.org/show_bug.cgi?id=13536 > > https://issues.dlang.org/show_bug.cgi?id=13537 > > https://issues.dlang.org/show_bug.cgi?id=14136 > > https://issues.dlang.org/show_bug.cgi?id=14138 > > > >There are probably other holes that we haven't discovered yet. > > Yah, @safe is in need of some good TLC. How about we make it a > priority for 2.068? If we're going to do that, let's do it right. Let's outlaw everything in @safe and then start expanding it by adding explicitly-vetted operations. See below. > >All in all, it's not looking like much of a guarantee right now. > >It's more like a cheese grater. > > > >This is a symptom of the fact that @safe, as currently implemented, > >starts by assuming the whole language is @safe, and then checking for > >exceptions that are deemed unsafe. Since D has become quite a large, > >complex language, many unsafe operations and unsafe combinations of > >features are bound to be overlooked (cf. combinatorial explosion), > >hence there are a lot of known holes and probably just as many, if > >not more, unknown ones. > > I'd have difficulty agreeing with this. The issues you quoted don't > seem to follow a pattern of combinatorial explosion. No, what I meant was that in an "assume safe unless proven otherwise" system, there's bound to be holes because the combinatorial explosion of feature combinations makes it almost certain there's *some* unsafe combination we haven't thought of yet that the compiler currently accepts. And it may be a long time before we discover this flaw. This means that the current implementation almost certainly has holes (and in fact it has quite a few known ones, and very likely more as-yet unknown ones), therefore it's not much of a "guarantee" of safety at all. What I'm proposing is that we reverse that: start with prohibiting everything, which is by definition safe, since doing nothing is guaranteed to be safe. Then slowly add to it the things that are deemed safe after careful review, until it becomes a usable subset of the language. This way, we actually *have* the guarantee of safety from day one, and all we have to do is to make sure each new addition to the list of permitted operations doesn't introduce any new holes. And even in the event that it does, the damage is confined because we know exactly where the problem came from: we know that X commits in the past @safe had no holes, and now there's a hole, so git bisect will quickly locate the offending change. Whereas in our current approach, everything is permitted by default, which means the safety guarantee is broken *by default*, except where we noticed and plugged it. We're starting with a cheese grater and plugging the holes one by one, hoping that one day it will become a solid plate. Why not start with a solid plate in the first place, and make sure we don't accidentally punch holes through it? > On another vein, consider that the Java Virtual Machine has had for > many, many years bugs in its safety, even though it was touted to be > safe from day one. With each of the major bugs, naysayers claimed it's > unfixable and it belies the claim of memory safety. Fallacy: Language X did it this way, therefore it's correct to do it this way. > A @safe function may assume that the code surrounding it has not > broken memory integrity. Under that assumption, it is required (and > automatically checked) that it leaves the system with memory > integrity. This looks like a reasonable stance to me, and something > I'm committed to work with. That's beside the point. Assuming the surrounding context is safe or not has no bearing on whether certain combinations of operations inside the @safe function has unsafe semantics -- because the compiler failed to recognize a certain construct as unsafe. The latter is what I'm talking about. > >Trying to fix them is like playing whack-a-mole: there's always yet > >one more loophole that we overlooked, and that one hole compromises > >the whole system. Not to mention, every time a new language feature > >is added, @safe is potentially compromised by newly introduced > >combinations of features that are permitted by defau
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 15:35:46 UTC, H. S. Teoh wrote:
@safe has some pretty nasty holes right now... like:
https://issues.dlang.org/show_bug.cgi?id=5270
https://issues.dlang.org/show_bug.cgi?id=8838
My new reference safety system:
http://forum.dlang.org/post/offurllmuxjewizxe...@forum.dlang.org
...would solve the above two bugs. In fact, it's designed
precisely for bugs like those. Here's your failing use case for
bug 5270. I'll explain how my system would track and catch the
bug:
int delegate() globDg;
void func(scope int delegate() dg) {
globDg = dg; // should be rejected but isn't
globDg();
}
If func is marked @safe and no attribute inference is permitted,
this would error, as it copies a reference parameter to a global.
However, let's assume we have inference. The signature would now
be inferred to:
void func(noscope scope int delegate() dg);
Yeah it's obviously weird having both `scope` and `noscope`, but
that's pure coincidence, and moreover, I think the use of `scope`
here would be made obsolete by my system anyway. (Note also that
the `noscope` bikeshed has been suggested to be painted `static`
instead -- it's not about the name, yet... ;-)
void sub() {
int x;
func(() { return ++x; });
}
Well I suppose this rvalue delegate is allocated on the stack,
which will have local reference scope. This is where you'd get
the safety error in the case of attribute inference, as you can't
pass a local reference to a `noscope` parameter. The rest is just
a foregone conclusion (added here for completion):
void trashme() {
import std.stdio;
writeln(globDg()); // prints garbage
}
void main() {
sub();
trashme();
}
The next bug, 8838, is a very simple case, I think:
int[] foo() @safe
{
int[5] a;
return a[];
}
`a`, being a static array, would have a reference scope depth of
1, and when you copy the reference to make a dynamic array in the
return value, the reference scope inherits that of `a`. Any scope
system would catch this one, I'm afraid. Mine seems like overkill
in this case. :-/
Re: Contradictory justification for status quo
Andrei Alexandrescu: Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. I have suggested to switch to @safe by default: https://issues.dlang.org/show_bug.cgi?id=13838 Bye, bearophile
Re: Contradictory justification for status quo
On 2/27/15 7:33 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. [...] @safe has some pretty nasty holes right now... like: https://issues.dlang.org/show_bug.cgi?id=5270 https://issues.dlang.org/show_bug.cgi?id=8838 https://issues.dlang.org/show_bug.cgi?id=12822 https://issues.dlang.org/show_bug.cgi?id=13442 https://issues.dlang.org/show_bug.cgi?id=13534 https://issues.dlang.org/show_bug.cgi?id=13536 https://issues.dlang.org/show_bug.cgi?id=13537 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14138 There are probably other holes that we haven't discovered yet. Yah, @safe is in need of some good TLC. How about we make it a priority for 2.068? All in all, it's not looking like much of a guarantee right now. It's more like a cheese grater. This is a symptom of the fact that @safe, as currently implemented, starts by assuming the whole language is @safe, and then checking for exceptions that are deemed unsafe. Since D has become quite a large, complex language, many unsafe operations and unsafe combinations of features are bound to be overlooked (cf. combinatorial explosion), hence there are a lot of known holes and probably just as many, if not more, unknown ones. I'd have difficulty agreeing with this. The issues you quoted don't seem to follow a pattern of combinatorial explosion. On another vein, consider that the Java Virtual Machine has had for many, many years bugs in its safety, even though it was touted to be safe from day one. With each of the major bugs, naysayers claimed it's unfixable and it belies the claim of memory safety. A @safe function may assume that the code surrounding it has not broken memory integrity. Under that assumption, it is required (and automatically checked) that it leaves the system with memory integrity. This looks like a reasonable stance to me, and something I'm committed to work with. Trying to fix them is like playing whack-a-mole: there's always yet one more loophole that we overlooked, and that one hole compromises the whole system. Not to mention, every time a new language feature is added, @safe is potentially compromised by newly introduced combinations of features that are permitted by default. There aren't many large features to be added, and at this point with @safe being a major priority I just find it difficult to understand this pessimism. Probably a good thing to do, whether you're right or overly pessimistic, is to fix these bugs. In the worst case we have a slightly tighter "cheese grate". In the best case we get to safety. Rather, what *should* have been done is to start with @safe *rejecting* everything in the language, and then gradually relaxed to permit more operations as they are vetted to be safe on a case-by-case basis. Yah, time travel is always so enticing. What I try to do is avoid telling people sentences that start with "You/We should have". They're not productive. Instead I want to focus on what we should do starting now. See: https://issues.dlang.org/show_bug.cgi?id=12941 I'm unclear how this is actionable. Andrei
Re: Contradictory justification for status quo
On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] > Safety is good to have, and the simple litmus test is if you slap > @safe: at the top of all modules and you use no @trusted (or of course > use it correctly), you should have memory safety, guaranteed. [...] @safe has some pretty nasty holes right now... like: https://issues.dlang.org/show_bug.cgi?id=5270 https://issues.dlang.org/show_bug.cgi?id=8838 https://issues.dlang.org/show_bug.cgi?id=12822 https://issues.dlang.org/show_bug.cgi?id=13442 https://issues.dlang.org/show_bug.cgi?id=13534 https://issues.dlang.org/show_bug.cgi?id=13536 https://issues.dlang.org/show_bug.cgi?id=13537 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14138 There are probably other holes that we haven't discovered yet. All in all, it's not looking like much of a guarantee right now. It's more like a cheese grater. This is a symptom of the fact that @safe, as currently implemented, starts by assuming the whole language is @safe, and then checking for exceptions that are deemed unsafe. Since D has become quite a large, complex language, many unsafe operations and unsafe combinations of features are bound to be overlooked (cf. combinatorial explosion), hence there are a lot of known holes and probably just as many, if not more, unknown ones. Trying to fix them is like playing whack-a-mole: there's always yet one more loophole that we overlooked, and that one hole compromises the whole system. Not to mention, every time a new language feature is added, @safe is potentially compromised by newly introduced combinations of features that are permitted by default. Rather, what *should* have been done is to start with @safe *rejecting* everything in the language, and then gradually relaxed to permit more operations as they are vetted to be safe on a case-by-case basis. That way, instead of having a long list of holes in @safe that need to be plugged, we *already* have guaranteed safety and just need to allow more safe operations that are currently prohibited. @safe bugs should have been of the form "operation X is rejected but ought to be legal", rather than "operation X is accepted but compromises @safe". In the former case we would already have achieved guaranteed safety, but in the latter case, as is the current situation, we don't have guaranteed safety and it's an uphill battle to get there (and we don't know if we'll ever arrive). See: https://issues.dlang.org/show_bug.cgi?id=12941 T -- Verbing weirds language. -- Calvin (& Hobbes)
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 14:02:58 UTC, Andrei Alexandrescu wrote: Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. A feature that is safe except for certain constructs is undesirable. It seems like you're agreeing with my general idea of "going the whole hog". Generally having a large number of corner cases that require special language constructs to address is a Bad Sign. But D inherits C's separate compilation model. All these cool function and parameter attributes (pure, @safe, return ref, etc.) could be kept hidden and just used and they would Just Work if D didn't have to accommodate separation compilation. From my perspective, the only "Bad Sign" is that D has to navigate the tradeoff between: * concise function signatures * accurate communication between functions * enabling separate compilation It's like you have to sacrifice one to get the other two. Naturally I'm not keen on this, so I rush to see how far attribute inference for all functions can be taken. Then Dicebot suggests automated .di file generation with statically verified matching binaries: http://forum.dlang.org/post/otejdbgnhmyvbyaxa...@forum.dlang.org The point is that I don't feel the ominous burden of a Bad Sign here, because of the inevitability of this conflict.
Re: Contradictory justification for status quo
On 2/26/15 8:21 PM, Zach the Mystic wrote:
Can I ask you a general question about safety: If you became convinced
that really great safety would *require* more function attributes, what
would be the threshold for including them? I'm trying to "go the whole
hog" with safety, but I'm paying what seems to me the necessary price --
more parameter attributes. Some of these gains ("out!" parameters, e.g.)
seem like they would only apply to very rare code, and yet they *must*
be there, in order for functions to "talk" to each other accurately.
Are you interested in accommodating the rare use cases for the sake of
robust safety, or do you just want to stop at the very common use cases
("ref returns", e.g.)? "ref returns" will probably cover more than half
of all use cases for memory safety. Each smaller category will require
additions to what a function signature can contain (starting with
expanding `return` to all reference types, e.g.), while covering a
smaller number of actual use cases... but on the other hand, it's
precisely because they cover fewer use cases that they will appear so
much less often.
Safety is good to have, and the simple litmus test is if you slap @safe:
at the top of all modules and you use no @trusted (or of course use it
correctly), you should have memory safety, guaranteed.
A feature that is safe except for certain constructs is undesirable.
Generally having a large number of corner cases that require special
language constructs to address is a Bad Sign.
Andrei
Re: Contradictory justification for status quo
On 2/27/15 1:09 AM, John Colvin wrote: On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote: I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. Everyone's a Marxist when it comes to their own labour :) Nice! -- Andrei
Re: Contradictory justification for status quo
On Thursday, 26 February 2015 at 20:35:04 UTC, deadalnix wrote: Yes, I don't care about the specific enum case, in fact, that is one of the least offender and this is why I choose it as an example here. Hmm. I still consider it a major issue and thought we agreed to introduce "final enum" to be used with "final switch" - and was sightly dissapointed that it didn't go in 2.067 How can we make progress, if even the things that have reached consens on are not promoted? Same goes for multiple "alias this".
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote: I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. Everyone's a Marxist when it comes to their own labour :)
Re: Contradictory justification for status quo
On Fri, 27 Feb 2015 06:34:40 +, weaselcat wrote: > On Friday, 27 February 2015 at 02:46:57 UTC, ketmar wrote: >> On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d >> wrote: >> >>> whereas creating a PR for dmd will sometimes put things in a position >>> where Walter finally approves it (or rejects it) rather than simply >>> discussing it and getting nowhere. >> >> oh, i see. i really enjoy multiple `alias this` now, it's a great >> merge! >> and that great new tuple syntax... i love it! >> >> ah, sorry, i was daydreaming. > > Didn't multiple alias this get merged? I wasn't even following it. it was blessed and... and then everybody forgot about it. signature.asc Description: PGP signature
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 02:46:57 UTC, ketmar wrote: On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d wrote: whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere. oh, i see. i really enjoy multiple `alias this` now, it's a great merge! and that great new tuple syntax... i love it! ah, sorry, i was daydreaming. Didn't multiple alias this get merged? I wasn't even following it.
Re: Contradictory justification for status quo
On 2/26/2015 6:58 PM, Andrei Alexandrescu wrote: I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. Yeah, that's always a problem. Ideally, how much work someone put into a proposal should have nothing to do with whether it is incorporated or not. But being human, we feel a tug to incorporate something because someone expended much effort on it. It's always much harder to turn them down.
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu
wrote:
I'm following with interest the discussion "My Reference Safety
System (DIP???)". Right now it looks like a lot of work - a
long opener, subsequent refinements, good discussion. It also
seems just that - there's work but there's no edge to it yet;
right now a DIP along those ideas is more likely to be rejected
than approved. But I certainly hope something good will come
out of it. What I hope will NOT happen is that people come to
me with a mediocre proposal going, "We've put a lot of Work
into this. Well?"
Can I ask you a general question about safety: If you became
convinced that really great safety would *require* more function
attributes, what would be the threshold for including them? I'm
trying to "go the whole hog" with safety, but I'm paying what
seems to me the necessary price -- more parameter attributes.
Some of these gains ("out!" parameters, e.g.) seem like they
would only apply to very rare code, and yet they *must* be there,
in order for functions to "talk" to each other accurately.
Are you interested in accommodating the rare use cases for the
sake of robust safety, or do you just want to stop at the very
common use cases ("ref returns", e.g.)? "ref returns" will
probably cover more than half of all use cases for memory safety.
Each smaller category will require additions to what a function
signature can contain (starting with expanding `return` to all
reference types, e.g.), while covering a smaller number of actual
use cases... but on the other hand, it's precisely because they
cover fewer use cases that they will appear so much less often.
Re: Contradictory justification for status quo
On 2/26/15 6:17 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Feb 26, 2015 at 05:57:53PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/26/15 5:48 PM, Zach the Mystic wrote: I sometimes feel so bad for Kenji, who has come up with several reasonable solutions for longstanding problems, *and* implemented them, only to have them be frozen for *years* by indecision at the top. Yah, we need to be quicker with making decisions, even negative. This requires collaboration from both sides - people shouldn't get furious if their proposal is rejected. Kenji has been incredibly gracious about this. [...] I don't think people would be furious if they knew from the beginning that something would be rejected. At least, most reasonable people won't, and I'm assuming that the set of unreasonable people who contribute major features is rather small (i.e., near cardinality 0). Well yes in theory there's no difference between theory and practice etc. What has happened historically (fortunately not as much lately) was that statistically most proposals have been simply Not Good. Statistically, proposal authors have been Positively Convinced that their proposals were of Obviously Excellent. (That includes me; statistically most ideas I've ever had have been utter crap, but seldom seemed like it in the beginning.) This cycle has happened numerous times. We've handled that poorly in the past, and we're working on handling it better. What *does* make people furious / disillusioned is when they are led to believe that their work would be accepted, and then after they put in all the effort to implement it, make it mergeable, keep it up to date with the moving target of git HEAD, etc., it then gets summarily dismissed. Or ignored for months and years, and then suddenly shot down. Or worse, get *merged*, only to be reverted later because the people who didn't bother giving feedback earlier now show up and decide that they don't like the idea after all. (It's a different story if post-merge rejection happened because it failed in practice -- I think reasonable people would accept that. But post-merge rejection because of earlier indecision / silence kills morale really quickly. Don't expect to attract major contributors if morale is low.) Yes, getting back on a decision or promise is a failure of leadership. For example, what happened with [$] was regrettable. We will do our best to avoid such in the future. I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it. What I hope will NOT happen is that people come to me with a mediocre proposal going, "We've put a lot of Work into this. Well?" Andrei
Re: Contradictory justification for status quo
On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d wrote: > whereas creating a PR for dmd will sometimes put things in a position > where Walter finally approves it (or rejects it) rather than simply > discussing it and getting nowhere. oh, i see. i really enjoy multiple `alias this` now, it's a great merge! and that great new tuple syntax... i love it! ah, sorry, i was daydreaming. signature.asc Description: PGP signature
Re: Contradictory justification for status quo
On Thu, Feb 26, 2015 at 05:57:53PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 2/26/15 5:48 PM, Zach the Mystic wrote: > >I sometimes feel so bad for Kenji, who has come up with several > >reasonable solutions for longstanding problems, *and* implemented > >them, only to have them be frozen for *years* by indecision at the > >top. > > Yah, we need to be quicker with making decisions, even negative. This > requires collaboration from both sides - people shouldn't get furious > if their proposal is rejected. Kenji has been incredibly gracious > about this. [...] I don't think people would be furious if they knew from the beginning that something would be rejected. At least, most reasonable people won't, and I'm assuming that the set of unreasonable people who contribute major features is rather small (i.e., near cardinality 0). What *does* make people furious / disillusioned is when they are led to believe that their work would be accepted, and then after they put in all the effort to implement it, make it mergeable, keep it up to date with the moving target of git HEAD, etc., it then gets summarily dismissed. Or ignored for months and years, and then suddenly shot down. Or worse, get *merged*, only to be reverted later because the people who didn't bother giving feedback earlier now show up and decide that they don't like the idea after all. (It's a different story if post-merge rejection happened because it failed in practice -- I think reasonable people would accept that. But post-merge rejection because of earlier indecision / silence kills morale really quickly. Don't expect to attract major contributors if morale is low.) T -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot
Re: Contradictory justification for status quo
On Friday, February 27, 2015 01:48:00 Zach the Mystic via Digitalmars-d wrote: > On Friday, 27 February 2015 at 01:33:58 UTC, Jonathan M Davis > wrote: > > Well, I suspect that each case would have to be examined > > individually to > > decide upon the best action, but I think that what it comes > > down to is the > > same problem that we have with getting anything done around > > here - someone > > has to do it. > > This isn't true at all. Things need to be approved first, then > implemented. If something is implemented, then there's an actual implementation to discuss and accept or reject, and sometimes that leads to the problem getting resolved, whereas just discussing it frequently just results in discussion rather than anything actually happening. Sure, if a decision isn't made before something is implemented, then the odds of it getting rejected are higher, and that can be very frustrating, but sometimes, it's the only way that anything gets done. > > With language changes, it's often the same. Someone needs to > > come up with a > > reasonable solution and then create a PR for it. They then > > have a much > > stronger position to argue from, and it may get in and settle > > the issue. > > I sometimes feel so bad for Kenji, who has come up with several > reasonable solutions for longstanding problems, *and* implemented > them, only to have them be frozen for *years* by indecision at > the top. I'll never believe your side until this changes. You can > see exactly how D works by looking at how Kenji spends his time. > For a while he's only been fixing ICEs and other little bugs > which he knows for certain will be accepted. I'm not saying any > of these top level decisions are easy, but I don't believe you > for a second, at least when it comes to the language itself. > Phobos may be different. Yes. Sometimes stuff gets rejected or stuck in limbo, but there's been plenty that has gotten done because someone like Kenji just decided to do it. The fact that stuff is stuck in limbdo for years is definitely bad - no question about it - but so much more wouldn't have been done had no one at least implemented something and tried to get it into the compiler or the standard library - especially when you're talking about the compiler. Language discussions frequently never result in anything, whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere. - Jonathan M Davis
Re: Contradictory justification for status quo
On 2/26/15 5:48 PM, Zach the Mystic wrote: I sometimes feel so bad for Kenji, who has come up with several reasonable solutions for longstanding problems, *and* implemented them, only to have them be frozen for *years* by indecision at the top. Yah, we need to be quicker with making decisions, even negative. This requires collaboration from both sides - people shouldn't get furious if their proposal is rejected. Kenji has been incredibly gracious about this. -- Andrei
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 01:33:58 UTC, Jonathan M Davis wrote: Well, I suspect that each case would have to be examined individually to decide upon the best action, but I think that what it comes down to is the same problem that we have with getting anything done around here - someone has to do it. This isn't true at all. Things need to be approved first, then implemented. With language changes, it's often the same. Someone needs to come up with a reasonable solution and then create a PR for it. They then have a much stronger position to argue from, and it may get in and settle the issue. I sometimes feel so bad for Kenji, who has come up with several reasonable solutions for longstanding problems, *and* implemented them, only to have them be frozen for *years* by indecision at the top. I'll never believe your side until this changes. You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I'm not saying any of these top level decisions are easy, but I don't believe you for a second, at least when it comes to the language itself. Phobos may be different.
Re: Contradictory justification for status quo
On Thursday, February 26, 2015 20:35:02 deadalnix via Digitalmars-d wrote: > On Thursday, 26 February 2015 at 11:10:16 UTC, Paolo Invernizzi > wrote: > > I think the real problem goes clearly beyond enums, it's an > > overall approach to changes in the D language itself. > > > > I join to deadalnix's worries. > > > > --- > > Paolo > > Yes, I don't care about the specific enum case, in fact, that is > one of the least offender and this is why I choose it as an > example here. > > What worries me is that whatever way you take the problem there > is a good reason not to proceed. And, taken independently, every > one of these reason are valid, or at least something reasonable > people can agree upon. > > But there is no way we can agree on all of these at once. Well, I suspect that each case would have to be examined individually to decide upon the best action, but I think that what it comes down to is the same problem that we have with getting anything done around here - someone has to do it. For instance, we all agree that std.xml needs to be replaced with something range-based and fast rather than what we currently have, but no one has made the time or put forth the effort to create a replacement and get it through the review process. Someone has to step up and do it, or it'll never get done. With language changes, it's often the same. Someone needs to come up with a reasonable solution and then create a PR for it. They then have a much stronger position to argue from, and it may get in and settle the issue. And it may not get merged, because it still can't be agreed upon as the correct solution, but an actual implementation carries a lot more weight than an idea, and in most of these discussions, we just discuss ideas without actually getting the work done. If we want stuff like this to get done then more of us need to find the time and put forth the effort to actually do it and be willing to have put forth the time and effort only to have our work rejected. But many of us are very busy, and we've failed to attract enough new contributors on big stuff to get many big things done by folks who haven't been doing a lot already. We probably need to find a way to encourage folks to do bigger things than simply making small improvements to Phobos - be it writing a potential, new module for Phobos or be it implementing critical stuff in the compiler. - Jonathan M Davis
Re: Contradictory justification for status quo
On Thursday, 26 February 2015 at 11:10:16 UTC, Paolo Invernizzi wrote: I think the real problem goes clearly beyond enums, it's an overall approach to changes in the D language itself. I join to deadalnix's worries. --- Paolo Yes, I don't care about the specific enum case, in fact, that is one of the least offender and this is why I choose it as an example here. What worries me is that whatever way you take the problem there is a good reason not to proceed. And, taken independently, every one of these reason are valid, or at least something reasonable people can agree upon. But there is no way we can agree on all of these at once.
Re: Contradictory justification for status quo
On Thursday, 26 February 2015 at 09:49:26 UTC, Jonathan M Davis wrote: On Wednesday, February 25, 2015 21:06:53 deadalnix via Digitalmars-d wrote: I'll use enum types as an example. I've seen this attitude going on on various topics. This is the surest and fastest way to end up with C++ without the C source compatibility. I'd like that we just stop this attitude. Personally, I think that the status quo with enums is horrible ... I think the real problem goes clearly beyond enums, it's an overall approach to changes in the D language itself. I join to deadalnix's worries. --- Paolo
Re: Contradictory justification for status quo
On Wednesday, February 25, 2015 21:06:53 deadalnix via Digitalmars-d wrote:
> Here is something I've noticed going on various time, recently in
> the memory management threads, but as to avoid an already heated
> debate, I'll use enum types as an example.
>
> We have a problem with the way enums are defined. If you have :
>
> enum E { A, B, C }
> E e;
>
> We have (1)
> final switch(e) with(E) {
> case A:
> // ...
> case B:
> // ...
> case C:
> // ...
> }
>
> But also have (2):
> typeof(E.A | E.B) == E
>
> When raising this, the discussion goes as follow
> - "If you have (1), we can't have (2), as break guarantee (1)
> rely on."
> - "(2) is usefull. For instance UserID or Color"
> - "Then let's get rid of (1)"
> - "(1) is useful, for instance to achieve X or Y"
> - "Let's create a new type in the language, (1) would be enum
> and (2) would be this new type"
> - "It adds too much complexity in the language"
>
> This very conversation went on in a very lengthy thread a while
> ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int
> and I consider it a closed issue).
>
> It can go forever, as all reason given for every concern raised
> is valid. Yes, adding a new type is probably too much for the
> benefit, yes (1) and (2) are useful in various scenarios. And, by
> refusing to take a step back look at the problem as a whole, we
> can turn around forever and never conclude anything, benefiting
> only the status quo.
>
> I've seen this attitude going on on various topics. This is the
> surest and fastest way to end up with C++ without the C source
> compatibility. I'd like that we just stop this attitude.
Personally, I think that the status quo with enums is horrible and that no
operation should be legal on them which is not guaranteed to result in a
valid enum value and that if you want to create a new type that can have
values other than those enumerated, you create a struct with some predefined
static values and don't use enums at all, but others disagree vehemently
(Andrei included). However, as it stands - as you point out - final switch
is completely broken, which is not a subjective issue at all but rather
quite an objective one. The solution that was proposed (by Andrei I think)
the last time that I was in a discussion on that was to introduce the
concept of "final enums" so that if you do something like
final enum E { A, B, C }
it's then the case that no operation on E is legal unless it's guaranteed to
result in an E (with casting being the way out when required, of course),
and then we would move towards making final switch illegal on normal enums.
I was going to create a DIP for it but forgot. I still think that it's
something that needs to be resolved though, since otherwise, enums are ugly
to work with (subjective though that may be), and final switch is broken.
- Jonathan M Davis
Re: Contradictory justification for status quo
On Wednesday, 25 February 2015 at 21:06:54 UTC, deadalnix wrote: This very conversation went on in a very lengthy thread a while ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int and I consider it a closed issue). If you keep the type, you can decompose the flag set when converting the value to string, see how C# does it: https://msdn.microsoft.com/en-us/library/vstudio/system.flagsattribute.aspx
Re: Contradictory justification for status quo
On 2015-02-25 22:06, deadalnix wrote:
Here is something I've noticed going on various time, recently in the
memory management threads, but as to avoid an already heated debate,
I'll use enum types as an example.
We have a problem with the way enums are defined. If you have :
enum E { A, B, C }
E e;
We have (1)
final switch(e) with(E) {
case A:
// ...
case B:
// ...
case C:
// ...
}
But also have (2):
typeof(E.A | E.B) == E
How about allowing something like this:
enum E : void { A, B, C }
The above would disallow use case (2). The compiler would statically
make sure a variable of type "E" can never have any value other than
E.A, E.B or E.C.
This should be completely backwards compatible since the above syntax is
currently not allowed. It also doesn't introduce a new type, at least
not syntactically.
--
/Jacob Carlborg
Contradictory justification for status quo
Here is something I've noticed going on various time, recently in
the memory management threads, but as to avoid an already heated
debate, I'll use enum types as an example.
We have a problem with the way enums are defined. If you have :
enum E { A, B, C }
E e;
We have (1)
final switch(e) with(E) {
case A:
// ...
case B:
// ...
case C:
// ...
}
But also have (2):
typeof(E.A | E.B) == E
When raising this, the discussion goes as follow
- "If you have (1), we can't have (2), as break guarantee (1)
rely on."
- "(2) is usefull. For instance UserID or Color"
- "Then let's get rid of (1)"
- "(1) is useful, for instance to achieve X or Y"
- "Let's create a new type in the language, (1) would be enum
and (2) would be this new type"
- "It adds too much complexity in the language"
This very conversation went on in a very lengthy thread a while
ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int
and I consider it a closed issue).
It can go forever, as all reason given for every concern raised
is valid. Yes, adding a new type is probably too much for the
benefit, yes (1) and (2) are useful in various scenarios. And, by
refusing to take a step back look at the problem as a whole, we
can turn around forever and never conclude anything, benefiting
only the status quo.
I've seen this attitude going on on various topics. This is the
surest and fastest way to end up with C++ without the C source
compatibility. I'd like that we just stop this attitude.
