On Thursday, February 17, 2011 18:08:15 David Simcha wrote:
>  Ok, I've come to the conclusion that we're never going to reach a
> consensus, so I'll lay a card on the table.  I never really liked the
> change that makes implicit narrowing conversions illegal (or most of the
> other increased strictness that D has acquired recently) in the first
> place.  This and many other things used to be a warning and to me that's
> exactly what they should be.  Warnings are for things that are
> unambiguous, have a decent probability of not being bugs, but also have a
> decent probability of being bugs.  Errors are for things that are
> ambiguous or are almost certainly bugs, or for when you explicitly asked
> for extra checking, for example by using const.  You might want the
> compiler to complain about narrowing conversions when you're trying to
> clean up the code, hunt for latent bugs that would only show up in
> production, and get to the "make it right" stage, or trying to figure out
> why it doesn't work.  Most narrowing conversions, though, are innocent and
> it's really annoying for the compiler to act like they need to be
> addressed right now, when you're still in the "make it work" stage or just
> writing some quick and dirty piece of code that only needs to run once.

Hmm. I'm definitely of the opinion that no responsible programmer will leave warnings in their program in the long run (though they may leave them while they're in the process of editing code), so I tend to not like the fact that warnings even exist. On some level, they're pointless because you shouldn't be leaving them in there any more than you leave errors in there. And too many programmers are willing to just leave them in there. On the other hand, sometimes it can be nice to leave a warning alone for a few minutes while you work on other issues. So, I'm generally divided on whether warnings should even exist. Walter is certainly against them.

I wouldn't be entirely opposed to narrowing conversions becoming a warning, but if that means that people start just leaving them in their code and not fixing the warnings, then that's _bad_. Narrowing conversions should _not_ just be left implicit in the code.

- Jonathan M Davis

I agree with Andrei.

My more general concern is that if we pump up Phobos with lots of little functions and aliases, we get a very large but not very useful library. We also increase the "cognitive load" of anyone attempting to understand standard D code.

When a standard library feature consists of 3 lines of trivial implementation, and 8 lines of documentation, that's a red flag to me that it shouldn't be in the library.

I'd really like to see library modules with small api's and large depth to them, like an XML parser.

On Thursday 17 February 2011 22:13:24 Walter Bright wrote:
> I agree with Andrei.
> 
> My more general concern is that if we pump up Phobos with lots of little functions and aliases, we get a very large but not very useful library. We also increase the "cognitive load" of anyone attempting to understand standard D code.
> 
> When a standard library feature consists of 3 lines of trivial implementation, and 8 lines of documentation, that's a red flag to me that it shouldn't be in the library.
> 
> I'd really like to see library modules with small api's and large depth to them, like an XML parser.

That's also an excellent example of code that you don't usually want to write yourself if you don't have to - which would be another key feature that standard library code should be aiming for. Sure, there's some trivial stuff that gets used all over the place that would be easy for people to write themselves but should be in the standard library simply because it's used so much, but in general, the standard library should be aiming to solve problems that are not only common but which are not the sort of thing that you want to be implementing yourself. An XML parser is a prime example of that. The e-mail address validation code is probably a good example as well, though it wouldn't be used as much. Something like ilength can be implemented and used by anyone in their own code fairly easily if they really want it.

- Jonathan M Davis