On 23/08/18 14:02, Walter Bright wrote:
On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
functions may be @safe, nothrow, @nogc, pure. If it's a method it
might also be const/inout/immutable, static. The number of libraries
that support all combinations is exactly zero (e.g. - when passing a
delegate in).
If, for example, a library functions allocates with the gc, then it
can't work with @nogc code. But still, fair enough - if there are
combinations which should work, but do not, please submit bug reports.
If you have already, is there a list of them?
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.
* Language complexity
Raise your hand if you know how a class with both opApply and the
get/next/end functions behaves when you pass it to foreach.
> How about a struct?
I presume you meant empty/front/popFront.
Indeed.
This is in the language spec:
How many people know that without resorting to the specs.
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.
* Critical bugs aren't being solved
People keep advertising D as supporting RAII. I'm sorry, but "supports
RAII" means "destructors are always run when the object is destroyed".
If the community (and in this case, this includes Walter) sees a bug
where that doesn't happen as not really a bug, then there is a deep
problem, at least, over-promising. Just say you don't support RAII and
destructors are unreliable and live with the consequences.
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.
#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.
When I talked to you about it at the last DConf, I got a reply that
could be largely summarized as "yeah, we should probably do some flow
analysis, sometimes".
The only time I got anyone to take this problem seriously was when
someone on the forum would claim that D supports RAII, to which I tend
to reply with "no, it doesn't".
So you will excuse me, but I don't think this bug is being taken as
seriously as I think it should.
I get it, it is not a simple bug to solve. It is an unfortunate truth
that some important bugs are not going to be easy. C++ went a different
path with this (strictly setting when members are initialized). I get
that this is a very unpopular feature of C++, and I can see why, but
seeing how D struggles to resolve this issue, I can't say it is a
mistake on C++'s behalf.
Shachar
