On 8/25/2018 2:46 PM, David Nadlinger wrote:
> On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
>> If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this?
> 
> At least for the transition period, I'd have attributes only apply to the user-specified code and infer them for the actual full constructor. (We can still print a deprecation warning if they don't match.) —David

Inferring is not good enough, for example:

https://github.com/dlang/dmd/pull/6816#issuecomment-307972790

There the @safe constructor is calling a destructor that calls free(). It can't be inferred as @safe. Sure, we can do warnings and deprecations, but the user will sooner or later have to change his code, and Chris' code from 2009 is not going to compile without changes.

---

A further issue with inferring for destructors is that why do it for destructors and not other member functions? It's a good question, without obvious answers.

---

The larger issue here is there is no solution where someone's ox doesn't get gored. I have to make a judgement call on what is overall best for the future of D. And the ox gets inevitably gored.

Even C, probably the slowest moving major language, has these issues.

On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote:
> And yet some of the heaviest users of D have said in public 'please break our code".  I wonder why that could be.

My answer to that is simply:

Break stuff so it becomes STABLE! Remove junk and clutter.
Do NOT break stuff to add more unneeded features inside a rotten carcass.

Be honest, how many people will use BetterC in production! Not as some homework or sided projects with a few dozen lines. Very few and that is the issue ... That is development time that can have gone into documentation, bug fixes...

On Saturday, 25 August 2018 at 22:55:05 UTC, RhyS wrote:
> Be honest, how many people will use BetterC in production!

Much, MUCH more likely than that I would ever use full D with GC in production.

Really, if I want a language with a GC, D is not that good. Why wouldn't I use a JVM language (Java, Kotlin, Scala) or Go or something else? Notice how they all have precise GCs? Or maybe I'd use a functional language like OCaml or Haskell. Same deal, precise GC.

The truth is that D is by design NOT a replacement for C++ when a low level systems programming language must be used. DasBetterC is close to what I'd like when I have to use C++, but not yet ideal. I'm starting to think that Rust (or, C++ 17 and beyond) will win this battle because every other language shows up with stuff I don't want.

On Saturday, 25 August 2018 at 20:19:44 UTC, Walter Bright wrote:
> On 8/25/2018 6:32 AM, Timon Gehr wrote:
>> (Or at least, not wrong. Using e.g. `void*` instead of an incompatible type would already be an improvement.)
>
> Making it void* is a reasonable idea.

If/when (I really hope the latter) DIP 1011 gets in it should be extern(delegate) with `ref typeof(this)` as the first parameter.

On Saturday, 25 August 2018 at 22:55:05 UTC, RhyS wrote:
> On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote:
>> And yet some of the heaviest users of D have said in public 'please break our code".  I wonder why that could be.
>
> My answer to that is simply:
>
> Break stuff so it becomes STABLE! Remove junk and clutter.
> Do NOT break stuff to add more unneeded features inside a rotten carcass.
>
> Be honest, how many people will use BetterC in production! Not as some homework or sided projects with a few dozen lines. Very few and that is the issue ... That is development time that can have gone into documentation, bug fixes...

I think you need to look at Dlang as what it is - still WIP and mostly *community driven*.

I got used to the occasional breaking or regression, and the best I can advise is to try to report or fix them if you can. There are still lots of things to be removed/added/or fixed in the language and the standard libraries - breakage will appear, and looks that most users expect some kind of breakage.

As for DasBetterC, you might underestimate the potential it has for migrating old C code fully of partially to D, or the nice thing that it enabled Webassembly targeting.
But for me it is important in the way that it acted as a catalyst for people to look at the issues Dlang and Druntime had, and made them better by making them more modular. This is a win for Dlang in the long run, maybe the betterC flag will be removed at some point because the compiler and runtime will be smart enough to enable pay-as-you-go intrinsically.

On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
> On 8/25/2018 3:52 AM, Chris wrote:
>> On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
>>> Every programmer who says this also demands new (and breaking) features.
>> "Every programmer who..." Really?
>
> You want to remove autodecoding (so do I) and that will break just about every D program in existence. For everyone else, it's something else that's just as important to them.
>
> For example, Shachar wants partially constructed objects to be partially destructed, a quite reasonable request. Ok, but consider the breakage:
>
>   struct S {
>     ~this() {}
>   }
>
>   class C {
>     S s;
>
>     this() nothrow {}
>   }
>
> I.e. a nothrow constructor now must call a throwing destructor. This is not some made up example, it breaks existing code:
>
>   https://github.com/dlang/dmd/pull/6816
>
> If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this?

Run semantic3 on the constructor independent of the requirement to destruct already constructed objects. If the constructors is nothrow then there is no need to have the destructors run or the eh code at all, because no Exceptions can be thrown (an Error may be thrown but that will kill the program). This is how I intend to fix it after I refactor semantic3.

On Saturday, 25 August 2018 at 22:53:44 UTC, Walter Bright wrote:
> On 8/25/2018 2:46 PM, David Nadlinger wrote:
>> At least for the transition period, I'd have attributes only apply to the user-specified code and infer them for the actual full constructor. (We can still print a deprecation warning if they don't match.) —David
>
> Inferring is not good enough, for example:
>
> https://github.com/dlang/dmd/pull/6816#issuecomment-307972790
>
> There the @safe constructor is calling a destructor that calls free(). It can't be inferred as @safe.

How did you interpret "only apply to the user-specified code"? In this example, the `@safe` in `this() @safe {}` would only apply to `{}`.

This necessitates being careful with the error message in a case like this

  struct UnsafeDtor { @system ~this() {} }

  struct Foo {
    UnsafeDtor ud;
    this(int a) @safe {
      if (!a) throw Exception("boo");
    }
  }

  void bar() @safe {
    auto f = Foo(1);
  }

as just printing "cannot call @system constructor" would be a bit misleading. It should work without surprises otherwise, though, and can be supplemented with deprecation warnings if the specified "inner" and inferred "outer" attributes don't match.

  —David

On Saturday, 25 August 2018 at 23:46:54 UTC, Radu wrote:

>
> I think you need to look at Dlang as what it is - still WIP and mostly *community driven*.
>
> I got used to the occasional breaking or regression, and the best I can advise is to try to report or fix them if you can. There are still lots of things to be removed/added/or fixed in the language and the standard libraries - breakage will appear, and looks that most users expect some kind of breakage.
>

This is not good enough. Yes, D users expect "some kind of breakage" - all the time, and this is exactly the problem. In D people have put up with breakages for too long believing things will improve in the long run, and because of this it is assumed that users will put up with it forever and ever and ever. Has it never occurred to anyone that many users have got sick and tired of this? I mean, there are other languages out there and you can get things done in no time and your program will still compile next week. I say it again, D has come a long way and things were looking good, but it's going nowhere. Look at this thread. Very intelligent people, top programmers, top engineers are arguing over details, while users (of D) who are programming for other users are trying to say "Stop!".

There's a huge difference between developing D and developing _in_ D.

On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote:
> Just found by chance, if someone is interested [1] [2].
>
> /Paolo
>
> [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md
> [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html

My summary of this discussion

* D as a language have issues, issues serious enough that they cannot be fixed without introducing breaking changes, which more or less means creating a spinoff language, or languages

* D as a project have issues, those cannot be fixed, because D's main attraction is Andrei and Walter are both the problem and the solution, again, no real solution unless their is a spinoff languages owned by a different group

I think that a lot of the complainers, are expecting that either Andrei or Walter, will create a new version of D that is basically a new language, or that they will explicitly create a new language that have all of D good points but none of the bad

I dont think that Andrei or Walter, are interested in creating a new language, I think they will keep trying to improve D incrementally

As a realistic short term fix, I think both Andrei and Walter, need to streamline and be more vocal about long term plans, because this is obviously a source of confusion for many, and a source for a lot of rants

On Sunday, 26 August 2018 at 03:17:06 UTC, Ali wrote:
> As a realistic short term fix, I think both Andrei and Walter, need to streamline and be more vocal about long term plans, because this is obviously a source of confusion for many, and a source for a lot of rants

My summary is that D means different things to different people. D has put in the kitchen sink. It tries to please everyone which means it is a complex toolbox. One thing I have learnt by lurking in this project is how much effort goes into compiler/library development to make it great. NoGC and safe just show how hard that can be. Lots of work on corner cases. Maybe with hindsight D should have been less OOP and more FP (destructuring data anyone?), but then you lose all those who want/are used to that paradigm.

I use quite a few languages. For me D is the most powerful language I have for getting performance. Artem wrote Sambamba as a student

    https://github.com/biod/sambamba

and it is now running around the world in sequencing centers. Many many CPU hours and a resulting huge carbon foot print. The large competing C++ samtools project has been trying for 8 years to catch up with an almost unchanged student project and they are still slower in many cases.

    https://groups.google.com/forum/#!topic/sambamba-discussion/z1U7VBwKfgs

Just saying. Much better to choose D over C++. I also work on a C++ project and I find it to be a royal pain compared to writing software in D.

Note that Artem used the GC and only took GC out for critical sections in parallel code. I don't buy these complaints about GC.

The complaints about breaking code I don't see that much either. Sambamba pretty much kept compiling over the years and with LDC/LLVM latest we see a 20% perfomance increase. For free (at least from our perspective). Kudos to LDC/LLVM efforts!!

Very excited to see gdc pick up too. We need the GNU projects.

So, do we need change? You can always try and improve process and over the last years W&A have been pushing for that.

Let me state here that  D is anarchy driven development in all its glory (much like the Linux kernel). I believe it is great.

I think, in addition to standard packaging in Linux distros (which is coming), D could use more industry support (much like the Linux kernel). D being a performance language for software engineers I would look at the extremes of HPC and mobile to succeed. How do we wake those companies up? Especially those with large investments in C++. Those we should invite to Dconf.

I remember one guy at Google telling me that every time someone would bring up "Why don't we write this in D instead?". That was 10 years ago. Google invested in Python and Go instead - but still write heaps of code in C++. Go figure.