try/catch idiom in std.datetime

[Ary Borenszweig]

On 11/19/13 10:39 PM, H. S. Teoh wrote:
> On Tue, Nov 19, 2013 at 08:30:18PM -0500, John J wrote:
>> On 11/19/2013 04:21 PM, Andrei Alexandrescu wrote:
> [...]
>>> That's exactly my point. The matter of fact is, in a setting where
>>> people are paid to write code, this kind of minor issue would be
>>> settled around the first week since hiring. At Facebook for example
>>> you'd be submitting a phabricator diff (loosely equivalent to a
>>> github pull request) and our linter will point out we use two spaces
>>> for indentation instead of tabs, and 80 columns. Then a couple of
>>> peers would point out that code is about twice as sparse vertically
>>> than it should. You'd fix these issues for good and that would be
>>> that. This has happened quite a few times. If, on the other hand, you
>>> chose to make a big deal out of it, that would be a cultural mismatch
>>> that to my knowledge would be unprecedented.
> [...]
>> This is great stuff for every developer to learn, but can someone
>> please create (or start creating) a code formatting tool for D?
>> I guess it's even worth putting some bounties on it, if that helps.
>
> The main holdup is the lack of a ready-made, official D lexer/parser.
> Nobody wants to manually maintain their own version of the D
> lexer/parser given how fast the language is still developing (plus, it
> sucks to have to keep fixing lexing/parsing bugs just because DMD's
> lexer/parser doesn't quite work the way you thought it would).
>
> Once we have this in place, I'm quite confident that a lot of nice D
> tools would spring up. Pretty-printing is, after all, one of the
> simplest uses of lexers/parsers.

One day you should all stop doing what you are doing and focus on 
bootstrapping the compiler. Then you will have a lexer/parser that's 
always consistent with the language. And you will have a very big 
program that will make it harder to introduce bugs in next versions. And 
it will show you where you need improvements to the language.

It's really sad that D is a system's programming language but its 
compiler is written in another language.

The strategy I would use is:

1. Copy the code as-is from C++ to D.
2. Make the smallest changes to make it work, even if it doesn't look 
like D code.

At this point, you will have a working compiler in D and a lexer/parser 
as libraries, that are always in-sync with the language.

Then:

3. Refactor the code to make it more D-ish.

Remember: the more you wait for this to happen, the harder it will be.

Just... stop, take some time, and do it.