On 24.08.2018 21:42, tide wrote:
> 
> Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate

That is indeed broken behavior (and I think there is a DIP to fix it), but member function pointers are not really a necessary language feature.

> where C++ has member function pointers, D just has broken unusable code.

You can use a

T function(ref S, Args)

in place of a

T (S::*)(Args)

(for S a value type, otherwise you don't need the ref).

Then, instead of

auto mptr = &S::foo;

you write

auto mptr = (ref S s, Args args) => s.foo(args);

(This is a bit more typing, but it can be automated, such that you only write getMPtr!(S.foo) or similar.)

instead of

s->*mptr(args)

you write

mptr(s, args)

The syntax is more obvious, it is more general, and at least some C++ compilers will do the same thing under the hood.

On 24.08.2018 22:46, Timon Gehr wrote:
> 
> s->*mptr(args)
> 
> you write
> 
> mptr(s, args)

Oops.

Wither the first code sample should be

s.*mptr(args)

or the second code sample should be

mptr(*s, args)

On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote:
>
> I got bitten by this just yesterday.  Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/

While we're airing grievances about code breakages, I hit this little gem the other day, and it annoyed me enough to complain about it: https://github.com/dlang/phobos/pull/5291#issuecomment-414196174

What really gets me is the actual removal of the symbol. If it had been left there with a deprecation message, I would've caught the problem immediately at the source and fixed it in a few minutes. Instead, I spent an hour or so tracing "execution" paths through a codebase that I'm unfamiliar with to figure out why a static if branch is no longer being taken.

On the topic of this thread... I was a bit confused with Dicebot's decision to leave at the time, because he seemed to like dip1000 but then later had a heel turn and left. Looking back through newsgroup threads, it seems like it was mostly that he disagreed with the project management side of things (which he also brings up in his article); an incomplete version of the feature being merged with code in the main branch having to be adjusted to support it. People have complained about it before, and it's distressingly common in D. Why it's not done in a feature branch and then merged in, I don't know, but I do agree with his objections.

On 8/24/18 5:12 PM, Meta wrote:
> On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote:
>>
>> I got bitten by this just yesterday.  Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/
> 
> While we're airing grievances about code breakages, I hit this little gem the other day, and it annoyed me enough to complain about it: https://github.com/dlang/phobos/pull/5291#issuecomment-414196174
> 
> What really gets me is the actual removal of the symbol. If it had been left there with a deprecation message, I would've caught the problem immediately at the source and fixed it in a few minutes. Instead, I spent an hour or so tracing "execution" paths through a codebase that I'm unfamiliar with to figure out why a static if branch is no longer being taken.

According to this comment: https://github.com/dlang/phobos/pull/5291#issuecomment-360929553

There was no way to get a deprecation to work.

When we can't get a deprecation to work, we face a hard decision -- actually break code right away, print lots of crappy errors, or just leave the bug unfixed.

-Steve

On Friday, 24 August 2018 at 21:43:45 UTC, Steven Schveighoffer wrote:
> According to this comment: https://github.com/dlang/phobos/pull/5291#issuecomment-360929553
>
> There was no way to get a deprecation to work.
>
> When we can't get a deprecation to work, we face a hard decision -- actually break code right away, print lots of crappy errors, or just leave the bug unfixed.
>
> -Steve

Ah, that's unfortunate. Damned if you do, damned if you don't.

I still don't agree with making a breaking change to Phobos.

On Fri, Aug 24, 2018 at 09:12:40PM +0000, Meta via Digitalmars-d wrote:
> On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote:
> > I got bitten by this just yesterday.  Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/
> 
> While we're airing grievances about code breakages, I hit this little gem the other day, and it annoyed me enough to complain about it: https://github.com/dlang/phobos/pull/5291#issuecomment-414196174
> 
> What really gets me is the actual removal of the symbol. If it had been left there with a deprecation message, I would've caught the problem immediately at the source and fixed it in a few minutes. Instead, I spent an hour or so tracing "execution" paths through a codebase that I'm unfamiliar with to figure out why a static if branch is no longer being taken.

Ironically, I was the one who pushed the merge button on that PR. :-/ Mea culpa.

But we had discussed this particular change at length before, and it was clear that there was no clean way to effect the change; every approach would lead to a mess. I forget the details now, but I think Jonathan's approach was the least of the evils among the options we had.

Though you do have an extremely good point about deprecating it first, or somehow warning the user in some way, so that when things do break, the solution is clear and doesn't require hours of tracing through 3rd party code.  I'm not sure if it was actually possible for deprecation to work on this particular change, but in any case, we should have tried harder to communicate the cause (and possible solution(s)) of the breakage to users.


> On the topic of this thread... I was a bit confused with Dicebot's decision to leave at the time, because he seemed to like dip1000 but then later had a heel turn and left. Looking back through newsgroup threads, it seems like it was mostly that he disagreed with the project management side of things (which he also brings up in his article); an incomplete version of the feature being merged with code in the main branch having to be adjusted to support it. People have complained about it before, and it's distressingly common in D. Why it's not done in a feature branch and then merged in, I don't know, but I do agree with his objections.

I think it's clear by now that most of D's woes are not really technical in nature, but managerial.  I'm not sure how to improve this situation, since I'm no manager type either.  It's a known problem among techies that we tend to see all problems as technical in nature, or solvable via technical solutions, when in reality what's actually needed is someone with real management skills.  Hammer and nail, and all that, y'know.

Unfortunately, we techies also tend to resist non-technical "interference", especially from non-techies (like manager types). I used to have that attitude too (and probably still do to some extent), and only with age did I begin realizing this about myself.  It's not an easy problem to fix in practice, especially in a place like here, where we're driven primarily by the technical aspects of D, and for the most part outside of any financial or other motivations that might have served to moderate things a little.


T

-- 
Some days you win; most days you lose.

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.

On Fri, Aug 24, 2018 at 09:48:33PM +0000, Meta via Digitalmars-d wrote:
> On Friday, 24 August 2018 at 21:43:45 UTC, Steven Schveighoffer wrote:
> > According to this comment: https://github.com/dlang/phobos/pull/5291#issuecomment-360929553
> > 
> > There was no way to get a deprecation to work.
> > 
> > When we can't get a deprecation to work, we face a hard decision -- actually break code right away, print lots of crappy errors, or just leave the bug unfixed.
> > 
> > -Steve
> 
> Ah, that's unfortunate. Damned if you do, damned if you don't.
> 
> I still don't agree with making a breaking change to Phobos.

I'm kinda on the fence about this, actually.  OT1H I actually *want* D to have breaking changes that will give longer-term benefits, like removing cruft that shouldn't have been there in the first place, or straightening out decisions that in retrospect were poorly made.

But OTOH I have also experienced the annoyance of random code breaking upon compiler upgrades, especially if the breakage happens in old code that I don't quite remember the intricacies of, or worse, in 3rd party code whose upstream has become non-responsive or has abandoned the project, or it's just too urgent to wait for upstream to address the problem, which I then have to debug and fix myself.

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.


T

-- 
People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)

On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote:
> On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:
> > I think that you're crazy.
>
> No, I just see more potential in D than you do.

To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. It's the kind of thing that's going to cause us way more work, more bugs, and make us that much less compatible with existing libraries. And for what? To _maybe_ get slightly better performance (which you probably won't get)? I honestly think that trying to bypass libc to talk to the kernel directly is actively worse than just using libc much as it would be great if we somehow lived in a world where every library we used was written in D. But the reality of the matter is that there is a _lot_ out there already written in C where it simply makes no sense to try to replace it. We're always going to need to interoperate with C unless we somehow convince all of the C developers to at least switch to -betterC (which obviously isn't happening).

- Jonathan M Davis

On 8/24/2018 12:42 PM, tide wrote:
> Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate where C++ has member function pointers, D just has broken unusable code. Or old features that were implemented poorly (C++ mangling for example).

How to do member function pointers in D:

https://www.digitalmars.com/articles/b68.html