try/catch idiom in std.datetime

[deadalnix]

On Thursday, 21 November 2013 at 06:35:35 UTC, Jonathan M Davis 
wrote:
> Definitely, but almost all arguments over coding style seem to 
> be very
> subjective even when some people try and claim that some of the 
> issues are
> objective. Most style choices which are objectively bad don't 
> even ever get
> made precisely because they're objectively bad. There are of 
> course
> exceptions, but I've rarely seen style arguments that are 
> actually objective,
> and it's not uncommon to have people with drastically different 
> opinions as to
> what looks good and who think that it should be obvious to 
> everyone that what
> they think looks good looks good and that the other style looks 
> horrible.
>
> And I've run into plenty of cases where one developer thinks 
> that a particular
> coding style is much easier to read, which is in complete 
> contrast with what
> another developer thought was legible (how many parens to use 
> and where being
> a prime example of that). So, it at least almost always seems 
> like what's
> considered be a good, legible style is very subjective.
>
> - Jonathan M Davis

It is because it is really context sensitive. Let me take a 
practical example.

function foo()
{
   return
   {
      foo: bar
   }
}

What does this JS sample returns ? Answer is : undefined 
(undefined is a thing in JS, not talking about undefined 
behavior). It is undefined because an semicolon is implicitly 
inserted after return.

It can take place in much more subtle forms.

How does it affect my D style ? It is quite simple, I integrated 
in JS that I should never ever ever put the brace on the next 
line. That is the worse idea ever. My work involve to do some JS, 
so I want to reduce as much as possible the cost of context 
switching and adopt a style that is consistent.

That is why I hate putting brace on the next line.

Indeed, in most language you'll find no objective reason why it 
is good or bad. But in JS you have an objective good reason to do 
it that way. And, as it reduce the cost of context switching, it 
make sense to do it in other languages (JS is not going to 
disappear soon).

Obviously, a dev that never do any JS will find this futile. 
Because he/she do not have to pay the same cost.