www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Contradictory justification for status quo

reply "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 25 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Feb 25 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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
Feb 25 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Feb 26 2015
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
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.
<snip>
 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
Feb 26 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 26 2015
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Feb 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Feb 26 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 26 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Feb 26 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 26 2015
next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Feb 26 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 27 2015
next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
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/otejdbgnhmyvbyaxatsk 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.
Feb 27 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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)
Feb 27 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 27 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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 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.
It's not about the size of a new feature. Every new feature, even a seemingly small one, causes an exponential growth in the number of language features one may put together, thereby increasing the surface area for some feature combinations to interact in unexpected ways. Surely you must know this, since this is why we generally try not to add new language features if they don't pull their own weight. The problem with this is that when compiling safe code, the compiler is not looking at a list of permitted features, but checking a list of prohibited features. So by default, new feature X (along with all combinations of it with existing language features) is permitted unless somebody took the pains to evaluate its safety in every possible context in which it might be used, *and* check for all those cases when compiling in safe mode. Given the size of the language, something is bound to be missed. So the safety guarantee may have been silently broken, but we're none the wiser until some unfortunate user stumbles upon it and takes the time to file a bug. Until then, safe is broken but we don't even know about it. If, OTOH, the compiler checks against a list of permitted features instead, feature X will be rejected in safe code by default, and we would slowly expand the scope of X within safe code by adding specific instances of it to the list of permitted features as we find them. If we miss any case, there's no problem -- it gets (wrongly) rejected at compile time, but nothing will slip through that might break safe guarantees. We just get a rejects-valid bug report, add that use case to the permitted list, and close the bug. Safety is not broken throughout the process. [...]
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.
[...] 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. (This will, of course, cause all safe code to no longer compile.) Then we slowly add back individual language features to the list of permitted operations in safe code until existing safe code successfully compiles. That gives us a reliable starting point where we *know* that safe is actually, y'know, safe. Of course, many legal things will now be (wrongly) rejected in safe code, but that's OK, because we will add them to the list of things permitted in safe code as we find them. Meanwhile, safe actually *guarantees* safety. As opposed to the current situation, where safe sorta-kinda gives you memory safety, provided you don't use unanticipated combinations of features that the compiler failed to recognize as unsafe, or use new features that weren't thoroughly checked beforehand, or do something blatantly stupid, or do something known to trigger a compiler bug, or ... -- then maybe, fingers crossed, you will have memory safety. Or so we hope. T -- Question authority. Don't ask why, just do it.
Feb 27 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 27 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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?
Feb 28 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/15 7:53 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
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
Feb 28 2015
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 27 2015
prev sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Feb 27 2015
prev sibling next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
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/offurllmuxjewizxedab 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. :-/
Feb 27 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 28 2015
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Feb 27 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 26 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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 :)
Feb 27 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 27 2015
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Feb 28 2015
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.)
Feb 28 2015
prev sibling parent reply "Sativa" <Sativa Indica.org> writes:
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.
Feb 28 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 28 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
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.
Feb 28 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Mar 01 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Mar 01 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Feb 26 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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!=20 and that great new tuple syntax... i love it! ah, sorry, i was daydreaming.=
Feb 26 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Feb 26 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 27 Feb 2015 06:34:40 +0000, 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.
=20 Didn't multiple alias this get merged? I wasn't even following it.
it was blessed and... and then everybody forgot about it.=
Feb 26 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Feb 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 28 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Mar 01 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
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.)
Mar 01 2015
prev sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Mar 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Mar 2015 00:48:54 +0000, Zach the Mystic wrote:

 I don't think anybody disagrees with this. Kenji's a miracle.
he's like Chuck Norris, only better. ;-)=
Mar 01 2015
prev sibling parent reply "Dominikus Dittes Scherkl" writes:
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".
Feb 27 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/27/2015 2:42 AM, Dominikus Dittes Scherkl wrote:
 How can we make progress,
Look at the changelog, there's tremendous progress.
Feb 28 2015