On Saturday, 25 August 2018 at 01:43:19 UTC, Walter Bright wrote:
> On 8/24/2018 4:22 PM, tide wrote:
>> struct SomeStruct
>> {
>>      void foo() {
>>          // use SomeStruct
>>      }
>> }
>> 
>> 
>> void broken()
>> {
>>      void function() foo = &SomeStruct.foo;
>>      foo(); // runtime error, isn't actually safe uses wrong calling convention as well
>> }
>> 
>> Not really lack of feature so much as there exists broken code. This has been valid code for god knows how long. At some point it was usable in @safe, but it looks you can't take an address of a member function without "this" as well in safe anymore.
>
>
> That's because it isn't safe. But being able to take the address is important for system work.

The stupid thing is you _have_ to cast (which is unsafe) the return type to be correct.

This could be solvable with DIP1011 to make &SomeStruct.foo return `extern(delegate) void function(ref Foo)` although it makes no explicit mention other than "member functions be implicitly convertible to extern(delegate) functions".

On Friday, 24 August 2018 at 21:57:55 UTC, Meta wrote:
> On Friday, 24 August 2018 at 21:53:18 UTC, H. S. Teoh wrote:
>> I think it's clear by now that most of D's woes are not really technical in nature, but managerial.

> Agreed.

>> I'm not sure how to improve this situation, since I'm no manager type either.

> Money is the only feasible solution IMO. How many people posting on this forum would quit their job tomorrow and solely contribute to OSS and/or work on their own projects if money wasn't an issue? The majority of people don't like being told what to do, and only want to work on what they're interested in. The only way to get them to work on something they're not interested in is to pay them.

As the discussion seed is a post from Mihails, I want to recall the author [1]:

"Didn't intend to chime in, but no, that was not what I have meant at all. My stance is that as long as current leadership remains in charge and keep sames attitude, no amount of money or developer time will fix D.

What is the point in hiring someone to manage things if Walter still can do stuff like -dip1000? For me moment of understanding this was exact point of no return."

What are the opinions on that, specifically on the attitude?

[1] https://forum.dlang.org/post/yadddavkoopieykhaczx@forum.dlang.org

/Paolo

On Friday, 24 August 2018 at 22:04:49 UTC, H. S. Teoh wrote:
> I don't know how to reconcile these two.  Perhaps if we had the manpower, we could maintain older versions for long enough to allow users to gradually rewrite to work with newer compilers, while the development branch can be bolder in making breaking changes that ultimately will result in a better, cleaner language.  But I doubt we have the kind of manpower it takes to maintain something like that.

In theory, it should be done so that there would be a longer-term unstable and and stable major branches.

Stable major branch would behave mainly like we do now: new features allowed and breaking changes also allowed, but only with proper deprectation processes.

In unstable major branch, you would do breaking changes, like removing autodecoding and exception throwing on general-purpose Phobos functions. No additional features here unless they depend on the breakages, to ease transitioning between the two.

Thwy would be merged like perhaps every ten versions.

I'm not saying this would necessarily work, but in theory it's the only way to get rid of historical babbage without becoming a moving target.

On Saturday, 25 August 2018 at 07:56:55 UTC, Walter Bright wrote:
> On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
>> No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object.
>
> All D objects are default-initialized before the constructor sees it (unlike C++). A destructor should be able to handle a default-initialized object.

Then we should add a switch to inject a unittest to run a destructor on a default initialisable object. i.e. if it has a static opCall or an @disable this(); then don't otherwise do. Otherwise this is a well disguised instance of faith based programming.

On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
> On 8/24/2018 6:04 AM, Chris wrote:
>> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.
>
> Every programmer who says this also demands new (and breaking) features.

"Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming. Earlier this year I had to "unearth" old Python code from 2009 (some parts of the code were even older). And you know what? It still worked! The same goes for Java code I wrote for Java 1.5. If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose.

Also, a. adding new features doesn't necessarily mean that old code has to stop working and b. the last breaking change I would've supported was to get rid of autodecode, but that was never done and now it seems too late, yet it would have been a change of utmost importance because string handling is everywhere these days. But maybe it would have been too much tedious work and no real intellectual challenge, so why bother. Other languages do bother, however.

You may brush our concerns aside with a throw away comment like the one above, but I'm not the only one who doesn't consider D for serious stuff anymore. As has been said before, none of the problems are unfixable - but if your answer is indicative of the D leadership's attitude towards concerned (longtime) users, then don't be surprised that we go back to Java and other languages that offer more stability.

I still have maximum respect for everything you, Andrei and the community have achieved. But please don't throw it all away now.

On Saturday, 25 August 2018 at 10:52:04 UTC, Chris wrote:
> On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
>> On 8/24/2018 6:04 AM, Chris wrote:
>>> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.
>>
>> Every programmer who says this also demands new (and breaking) features.
>
> "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming. Earlier this year I had to "unearth" old Python code from 2009 (some parts of the code were even older). And you know what? It still worked! The same goes for Java code I wrote for Java 1.5. If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose.
>
> Also, a. adding new features doesn't necessarily mean that old code has to stop working and b. the last breaking change I would've supported was to get rid of autodecode, but that was never done and now it seems too late, yet it would have been a change of utmost importance because string handling is everywhere these days. But maybe it would have been too much tedious work and no real intellectual challenge, so why bother. Other languages do bother, however.
>
> You may brush our concerns aside with a throw away comment like the one above, but I'm not the only one who doesn't consider D for serious stuff anymore. As has been said before, none of the problems are unfixable - but if your answer is indicative of the D leadership's attitude towards concerned (longtime) users, then don't be surprised that we go back to Java and other languages that offer more stability.
>
> I still have maximum respect for everything you, Andrei and the community have achieved. But please don't throw it all away now.


And yet some of the heaviest users of D have said in public 'please break our code".  I wonder why that could be.

It's also not terribly surprising that D2 code from 2009 doesn't always compile when you consider the release date of the language.

Do you think it's a bad thing that imports were fixed, for example?  That broke a lot of old code.

"If you want to achieve
> something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose.
"

I don't think this is true.  Have slices, arrays, associative arrays and so on broken ?  On the other hand D written like C that didn't get the imports right would have broken when the module system was corrected.  This is a good thing.

>
> "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming."

I don't think this is true either.  It doesn't fit with my own experience and it doesn't fit with the growing enterprise adoption.  That may be your personal perspective, but it's really hard to put yourself in the shoes of somebody in a very different situation that you have never encountered.

There's intrinsically a tradeoff between different kinds of problems.

Nassim Taleb writes about hormesis.  I'm not sure that breakage of a non-serious kind is necessarily terrible.  It might be terrible for you personally - that's not for me to judge.  But it has the effect of building capabilities that have value in other ways.

There are quite a few different sorts of concerns raised on this thread and they are linked by how people feel not by logic.  I have a lot of respect for Shachar technically but I personally found the way he expressed his point of view a bit odd and unlikely to be effective in achieving whatever it is his goal was, also bearing in mind he doesn't speak for Weka.

It might be helpful to go through the concerns and organise them based on logical ordering because an outburst of emotion won't translate in itself into any kind of solution.

On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote:

>
> Nassim Taleb writes about hormesis.  I'm not sure that breakage of a non-serious kind is necessarily terrible.  It might be terrible for you personally - that's not for me to judge.  But it has the effect of building capabilities that have value in other ways.
>
>

Unless you can afford to spend a lot of time on just fixing things, even small changes are annoying. I can understand that if a change is for the better in the long run it's worth breaking code, especially if you warn users so they know what's coming. But being "afraid" of every new version is not exactly a thing that encourages you to use D. Mind you, it's not just one program you have to maintain. Usually you have libraries and modules (and third party libs) that you haven't touched for a year or so and all of a sudden they don't compile anymore. You basically have to fix everything. And then there's vibe.d that has a hard time catching up with everything (Sönke is doing a great job, btw.) So you have a service based on vibe.d and somebody asks you to implement a trivial change (say sorting). You add it, compile it with the latest version of dmd and it gives you an error "XYZ is not supported when the moon is full". So you have to go back to a compiler version that works and you cannot benefit from e.g. the latest GC optimizations of D. You basically end up with a mess of different compilers for different code until you have fixed everything (which you don't have time for all the time). If your code is older than 2 or 3 versions of dmd, you are already in trouble and given the release frequency it happens quite fast.

Imagine, to fix a trivial bug or implement a simple feature you may have to stick to an outdated version of dmd or you have a ratio of 10% time spent on your own code 90% time spent on fixing what the latest release broke. Not good.

I am not being emotional, as you suggest. I'm talking about my practical experience and the challenges I face when I use D. And the prevalent attitude of "It's for your own good in the long run, you may not understand it now, but you will one day once you've followed the discussions on the forum and read the new specs!" is not helpful either when you need to get a job done. In the long run this might kill off D. And I'm someone who talks about it, imagine all the frustrated users who silently leave.

I have never encountered any such problems with any other language so far. Something tells me that there's something wrong with how D is managed.

On Saturday, 25 August 2018 at 01:43:19 UTC, Walter Bright wrote:
> On 8/24/2018 4:22 PM, tide wrote:
>> struct SomeStruct
>> {
>>      void foo() {
>>          // use SomeStruct
>>      }
>> }
>> 
>> 
>> void broken()
>> {
>>      void function() foo = &SomeStruct.foo;
>>      foo(); // runtime error, isn't actually safe uses wrong calling convention as well
>> }
>> 
>> Not really lack of feature so much as there exists broken code. This has been valid code for god knows how long. At some point it was usable in @safe, but it looks you can't take an address of a member function without "this" as well in safe anymore.
>
>
> That's because it isn't safe. But being able to take the address is important for system work.

Which is my point. Why did you link that article then? It's not safe due to the inherent flaw of D. It shouldn't return a function() type. This is invalid code just outright, the type system could easily be used to prevent this kind of mistake. But instead it relies on the user knowing about the bug in D. Hell like someone else mentioned, if it returned a delegate that would make more sense. But it doesn't for whatever reason. There's a lot of little things like this in D, and from your response you obviously don't give a flying shit about fixing it as you don't even see it as a problem. Just disable it in @safe and anyone that needs to write in @system will have to deal with insanity instead of having something reasonable.

On 25.08.2018 03:43, Walter Bright wrote:
> On 8/24/2018 4:22 PM, tide wrote:
>> struct SomeStruct
>> {
>>      void foo() {
>>          // use SomeStruct
>>      }
>> }
>>
>>
>> void broken()
>> {
>>      void function() foo = &SomeStruct.foo;
>>      foo(); // runtime error, isn't actually safe uses wrong calling convention as well
>> }
>>
>> Not really lack of feature so much as there exists broken code. This has been valid code for god knows how long. At some point it was usable in @safe, but it looks you can't take an address of a member function without "this" as well in safe anymore.
> 
> 
> That's because it isn't safe. But being able to take the address is important for system work.

So is taking the address of an `int` variable. The analogous point is that the type of `&x` for `x` an `int` should be `int*` (and not e.g. `string*`). D gets this right, and it should be equally obvious that it should get it right for the member function pointer case. (Or at least, not wrong. Using e.g. `void*` instead of an incompatible type would already be an improvement.)

On 25/08/18 10:56, Walter Bright wrote:
> On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
>> No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object.
> 
> All D objects are default-initialized before the constructor sees it (unlike C++). A destructor should be able to handle a default-initialized object.

I'm not talking about a default initialized object. I'm talking about an object where the constructor started running, but not to completion.

With that said, this statement is, I think, representative of the Lego problem D has. All D objects? Really? Even this one?

struct A {
  int a;

  @disable this();
  @disable init;

  this(int number);
  ~this();
}

If you allow a feature to be disabled, you really need to keep in mind that feature might be well and truly disabled.