bug?

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Sep 15 15:41:25 PDT 2016


On Thursday, September 15, 2016 15:15:49 Jonathan M Davis via Digitalmars-d-
learn wrote:
> On Thursday, September 15, 2016 18:15:52 deed via Digitalmars-d-learn wrote:
> > I'm curious when you would need to do only `new Struct[](1000);`
> > instead of
> > `auto structs = new Struct[](1000);`?
>
> Need to do? Probably never. It would be a pretty weird thing to do. But if
> Struct has a destructor that actually does stuff, then
>
>     new Struct[](1000);
>
> does not have no effect. Because the array is allocated on the GC heap, it's
> unknown when the destructors will run (and they may not ever actually run,
> because they'll only be run if a collection is run, and it collects that
> array), but it's still the case that removing that line will potentially
> change what the program does beyond just perfomance.
>
> For instance, as dumb as it would be, the destructor for Struct could do
> something like send an e-mail when it's run, and so if the compiler
> optimized out the array of Structs being allocated, those e-mails would not
> be sent, and the behavior of the program would change substantially.
>
> It would be a pretty rare case where it actually made sense for the
> programmer to just allocate an array like that and the let it go away. But
> the compiler has no way of knowing what the programmer intended. And if
> there's code that's actually run as a result of that line, then it's not
> true that it doesn't have any effect, and creating an error over it would be
> a bit much. Some compilers might warn about it, because the odds are very
> high that it was not intended, but Walter isn't big on warnings, and dmd
> didn't even have any for a long time - though he eventually did get worn
> down enough by requests for them that he gave in and added a few.
>
> The problem with warnings is that it's bad practice to leave warnings in
> your code (otherwise, it becomes way to easy to miss legitimate things that
> you've been warned about). And if you're not leaving warnings in your code,
> then they're really not any different from errors except for the fact that
> you don't have to immediately fix them to get your code to compile. So,
> arguably, warnings are pretty pointless, and that sort of thing is better
> left to a linter tool.  And something like _that_ probably would warn about
> code like this, because the odds are quite high that it's not what you meant
> to do.
>
> In general though, dmd tends to tell you when you did something definitely
> wrong but not say anything when you did something that you probably didn't
> mean to do but was perfectly legal.

I should probably point out that the issue here isn't really specifically
with

    new Struct[](100);

but rather with any statement that "has no effect." Once you start warning
about that, it can open a bit of a pandora's box - especially when it comes
to metaprogramming, which will often purposefully have statements that have
no effect, just so that it can test whether they compile.

But even without that, once you take stuff like constructors and destructors
into account, most statements potentially have an effect, making it so that
the number warnings that you could actualy give isn't necessarily all that
high. In comparison to C++, the fact that we don't have default constructors
for structs increases the number of cases where code can legitimately be
determined to have no effect, and the fact that we have pure functions can
do the same, but it's still the case that most statements that realistically
have no effect do run arbitrary code that the compiler would have to have
access to (which it doesn't always) and do a thorough examination of in
order to be sure that it truly has no effect. So, even if we had lots of
warnings in dmd and were looking to warn about something like this, it would
probably only make sense to warn for the really basic cases; otherwise, the
compiler ends up doing a lot of extra work for virtually no benefit, and in
many cases would be forced to assume that the code is doing something
anyway, because D's compilation model does not lend itself to deep
inspection of functions.

- Jonathan M Davis



More information about the Digitalmars-d-learn mailing list