On Saturday, 23 November 2013 at 01:48:28 UTC, Andrei Alexandrescu wrote:
> On 11/22/13 5:37 PM, growler wrote:
>> On Friday, 22 November 2013 at 21:48:14 UTC, Shammah Chancellor wrote:
>>
>> [snip]
>>>
>>> No.  scope(failure) is supposed to re-throw the exception.
>>
>> Where does it say that?
>>
>> http://dlang.org/statement.html#ScopeGuardStatement
>>
>> "... scope(failure) executes NonEmptyOrScopeBlockStatement when the
>> scope exits due to exception unwinding. ..."
>
> It's implied. The scope is already being exited by means of an exception. If scope(failure) changed anything, _that_ would have been documented.
>
> Anyhow we can be clearer in the docs.
>
>
> Andrei

I stand corrected, cheers.

On 2013-11-22 02:51:11 +0000, growler said:

> Maybe that's why it is considered broken? The first point was to 'fix' scope(failure) and then use it.
> 
> However, I don't know I haven't been following the discussion closely enough...

I think fixing it means disallowing return and assert(0) here.  Since these things generate unreachable code.  If it's fixed in the way I think it should be, it still wouldn't be useful here.

The proposed fix was to make it so scope(failure) assert(0);  Is detected as preventing the exception, so functions could be marked nothrow.   I don't think that's a good idea for the above reason.

I'd rather see Walter's proposed fix (http://forum.dlang.org/thread/l6ccae$2cmt$1@digitalmars.com?page=3#post-l6ds2b:241ii3:241:40digitalmars.com) of std.datetime, and my proposed fix for scope(failure).

-Shammah

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.