D is dead

[Walter Bright]

On 8/23/2018 4:31 AM, Shachar Shemesh wrote:
> None of that continues to work once delegates are involved. I am yet to see a 
> library that can accept a delegate and correctly create a function around it 
> that matches its attributes.
> 
> And yes, I do include Mecca in this. I tried. It is too difficult to get right, 
> so I gave up.
> 
> Attribute inference was supposed to solve this, but attribute inference is 
> completely broken with separate compilation.

I'd like to see an example so I can understand exactly what you're having 
trouble with.


>> This is in the language spec:
> How many people know that without resorting to the specs.

This is a little unfair. It's plainly stated in the documentation for foreach. 
Heck, I wrote a C compiler and the library for it, and yesterday I had to look 
up again how strncmp worked. I refer to the documentation regularly. Back when I 
designed digital circuits, I had a well-worn TTL data book on my desk, too. If 
it wasn't documented, or documented confusingly, it would be a fair point.


>>> Does it matter if it allows copying or not?
>> For the preference for opApply, no.
> But it does for empty/front/popFront, which is exactly my point.

If front() returns by ref, then no copying happens. If front() returns by value, 
then a copy is made. This should not be surprising behavior.


>> If you're referring to #14246, I posted a PR for it. I don't see how that is 
>> pretending it isn't a problem. It is.
> When I first reported this, about 3 and a half years ago, the forum explained to 
> me that this is working as expected.

The forum can be anyone saying anything. A more reliable answer would be the 
bugzilla entry being closed as "invalid", which did not happen.


> #14246 was over 2 years old by the time you posted the PR. Once posted, however, 
> it broke (I'm not sure why it broke, but did notice it deliberately would not 
> work with @disable init structs. See my interoperability comment from above). 
> Since then (over a year), no progress has been made except to revert the 
> changelog that claims it was resolved.

The problem was calling other destructors that had different attributes, such as 
the constructor being @safe but calling a destructor that was not. It's not an 
intractable problem, but I work on critical problems every day. It's just that 
everybody has a different issue that is critical to them.


> So you will excuse me, but I don't think this bug is being taken as seriously as 
> I think it should.

It is a serious problem. (There are workarounds available, like using 
scope(failure).)

I'd appreciate a list of bugzilla issues you regard as critical to your operations.