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.
