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?

In the whole discussion I miss 2 really important things.

If your product compiles fine with a dmd version, no one forces you to update to the next dmd version. In the company I work for, we set for each project the DMD version in the build settings. The speed of DMD releases or breaking changes doesn't affect us at all.

Maybe I do not know a lot open source products but the amount of work which goes into code quality is extremely high for the compiler, runtime, phobos and related products. I love to see how much work is invested in unit tests and also code style.

DMD (and LDC and GDC) has greatly improved in the last years in various aspects.

But I also see that there is a lot of work to be done. There are definitely problems to be solved. It is sad that people like Dicebot leaving the D community.

Kind regards
Andre

On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote:
> In the whole discussion I miss 2 really important things.
>
> If your product compiles fine with a dmd version, no one forces you to update to the next dmd version. In the company I work for, we set for each project the DMD version in the build settings. The speed of DMD releases or breaking changes doesn't affect us at all.

If your product is a library then your customers dictate which dmd version you build with.

On 8/25/2018 5:52 PM, David Nadlinger wrote:
> 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 `{}`.

I'm not sure what you're referring to. I'm referring to the specified message, and the example:

struct Array
{
    int[] _payload;
    ~this() // (2)
    {
        import core.stdc.stdlib : free;
        free(_payload.ptr); // (3)
    }
}

class Scanner
{
    Array arr;
    this() @safe {}  // (1)
}

In order for (1) to be @safe, then the destructor it calls for arr (2) must also be @safe. But the destructor calls free() (3), which is not @safe. Therefore, the compilation fails. Inference does not solve this problem, because (2) is inferred as @system.


> can be supplemented with deprecation warnings if the specified "inner" and inferred "outer" attributes don't match.

Yes, and that's probably the only viable way forward with this. But Chris' ox will get gored, as 2009 code will not compile anymore without modification after the deprecation period expires.

On Sunday, 26 August 2018 at 10:17:51 UTC, Walter Bright wrote:
> I'm not sure what you're referring to. I'm referring to the specified message, and the example:
>
> struct Array
> {
>     int[] _payload;
>     ~this() // (2)
>     {
>         import core.stdc.stdlib : free;
>         free(_payload.ptr); // (3)
>     }
> }
>
> class Scanner
> {
>     Array arr;
>     this() @safe {}  // (1)
> }
>
> In order for (1) to be @safe, then the destructor it calls for arr (2) must also be @safe. But the destructor calls free() (3), which is not @safe. Therefore, the compilation fails. Inference does not solve this problem, because (2) is inferred as @system.
>

Yes but if Scanners constructor is nothrow then all is fine, since it won't unwind unless an error is thrown in which case it game over anyway.

On Sunday, 26 August 2018 at 09:59:37 UTC, Peter Alexander wrote:
> On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote:
>> In the whole discussion I miss 2 really important things.
>>
>> If your product compiles fine with a dmd version, no one forces you to update to the next dmd version. In the company I work for, we set for each project the DMD version in the build settings. The speed of DMD releases or breaking changes doesn't affect us at all.
>
> If your product is a library then your customers dictate which dmd version you build with.

Why is this a problem? I have the exact same thought. This is not an unsolvable problem.

Package managers have solved this ages ago with a min-version flag.

The compiler can do the same if D is against just embracing the package manager as the way to do things.

If D has an LTS version and cutting edge then I don't see the problem:

a) You broke me lib! => Set a min-compilation version flag, or use LTS (you have both options)

- Qt does this.
- Node does this.
- iOS Foundation even gets rid of crap, and their user base is HUGE.
- Safari is completely revamping how cookies and storage APIs work. That's *universal*. Programmers are dealing with it.

Yes their user base is much bigger - so they can survive - is probably one subjective argument. But then if you have an LTS then what's the argument?

b) Why you no update D?! => use cutting edge.

The only problem I see is manpower.

Cheers,
- Ali

On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote:
> On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
>
> In the whole discussion I miss 2 really important things.
>
> If your product compiles fine with a dmd version, no one forces you to update to the next dmd version. In the company I work for, we set for each project the DMD version in the build settings. The speed of DMD releases or breaking changes doesn't affect us at all.

No. Nobody forces you to use the latest version that may have an improved GC, new library functions or bug fixes. In fact, why bother with improving the language at all? But how do you feel about code that you've been compiling with, say dmd 2.071.2 for years now - including workarounds for compiler bugs? Doesn't the thought of having to upgrade it one day bother you at all? What if your customer said that 2.08++ had better features asking you to use them?

The burden of finding paths to handle deprecations etc. is on the user, not the language developers. And this is where the psychological factor that Laeeth was talking about comes in. If you're constantly programming thinking "Whatever I write today might break tomorrow, uh, and what about the code I wrote in 2016? Well, I'll have to upgrade it one day, when I have time. I'll just keep on using an older version of dmd for now. Yeah, no, I cannot benefit from the latest improvements but at least it compiles with dmd2.st0neage. But why worry, I'll just have to get used to the fact that I have different code for different versions, for now...and forever."

You can get used to anything until you find out that it doesn't need to be this way. You write unexciting Java code and hey, it works and it always will. It took me a while to understand why Java has been so successful, but now I know. It's not write once, run everywhere. It's write once, run forever. Stability, predictability. And maybe that's why Java, Go and once C++ prefer a slower pace.

I just don't understand why it is so hard to understand the points I and others have made. It's not rocket science, but maybe this is the problem, because I already see, the point to take home is: There are no real problems, we are just imagining them. Real world experience doesn't count, because we just don't see the bigger picture which is the eternal glory of academic discussions about half baked features of an eternally unfinished language that keeps changing randomly. Not practical, but intellectually satisfying.

On Sunday, 26 August 2018 at 13:40:17 UTC, Chris wrote:
> You can get used to anything until you find out that it doesn't need to be this way. You write unexciting Java code and hey, it works and it always will. It took me a while to understand why Java has been so successful, but now I know.
A week ago or so I was considering a programming language for my new project. JVM (Kotlin) was one of alternatives and scored high in my list. The (big) problem was that JVM doesn't have structs. So I investigated (I don't actually know Java nor Kotlin). There was some library that apparently brings structs to Java, which seemed a bit dubious to me. Also, I found out there was an effort (at Oracle) to hack structs into Java.
Interestingly, it seemed that 14 people worked full time on that. 14 people to make it possible to use structs. So, yeah. It's not difficult to understand why Java is more "industrial-strength" than D. I don't know what exactly you expected.
I chose D in the end, as this project is something where it's reasonable to use D. And yes, I expect some problems that I just wouldn't have with Java/Kotlin or even with C++ (well, the latter has some pretty severe problems, IMO)

On Sunday, 26 August 2018 at 14:00:56 UTC, nkm1 wrote:
> [...]

What did I expect? Better: What do I expect now. I've been using D for years now. I think it's time for D to offer users the same stability as other languages do. Simple as.

On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
>
> 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.

I wanted to get rid of autodecode and I even offered to test it on my string heavy code to see what breaks (and maybe write guidelines for the transition), but somehow the whole idea of getting rid of autodecode was silently abandoned. What more could I do?

I am fully aware of the fact that it's always something else to someone else. But you can have a list of common sense priorities. For example, fast and efficient string handling should be up there, because in times of data mining and machine learning (cf. translation tools) string handling is _very_ important.

My suggestion is

- breakage only where it is absolutely necessary

- new features as opt in but not as breaking features

- new versions of dmd should be more tolerant of older code. Say, let's introduce a _guaranteed_ backwards compatibility of at least N versions. In this way one could work with the latest version (and benefit from new features, bug fixes, optimizations) and bit by bit upgrade old code as you go along.

- maybe introduce a feature freeze for a while and have a poll about which features are really being used on a day to day basis. In this way you can spend time on fixing stuff that is really needed instead of wasting time on features that are not really used that often (as seems to be the case with @safe)

- stick to a list of clear goals instead of taking on board random requests, interesting as they may be. In other words: more focused work, harden your heart a little bit ;)


> 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?

I have no opinion on this. But it's indicative of the way D is being developed atm. A half baked feature (partially constructed objects with no partial destructor) that if you fix it, breaks existing code. But what for was it introduced at all and why wasn't it thought through properly right from the start?

See if I donate (a humble amount of) money to the D foundation I don't want to see it used on experimental container library optimizations. I want it to be spent on D being turned into a sound and stable language with certain guarantees.

On Sunday, 26 August 2018 at 14:17:33 UTC, Chris wrote:
> On Sunday, 26 August 2018 at 14:00:56 UTC, nkm1 wrote:
>> [...]
>
> What did I expect? Better: What do I expect now. I've been using D for years now. I think it's time for D to offer users the same stability as other languages do. Simple as.

lurking around this board for a long time and gave up on d2 along time ago. it is to scripty. i can not convince anybody at work to use it even for small things under windows. some tried it and they say it is to buggy, misses windows essentials and there seems to be no chance of betterment via management or the compiler enthusiasts that rather implement any fancy fart instead of getting the compiler stable, bug free and usable.
it seems like this is a language experiment, unusable for serious development.
i just downloaded current beta 2 and visual D. installs ok, no detection of visual studio or any of the associated paths. visual D installed ok, but a click on menu options killed visual studio.
i uninstalled successfully - hallelujah.
so i lurk around for an other year an see if D experiment is still around and/or usable.