On Saturday, 8 February 2014 at 05:04:35 UTC, Jonathan M Davis
wrote:
> I think that that would call for us to have 3 related but distinct functions:
>
> 1. decode, which throws on invalid Unicode. We already have this.

I wonder if it'd be too reckless to just make decode for string
nothrow (we want this function to be as fast as possible) and
just require that string, by definition, must be valid unicode.
to!string and company could validate strings as they come in from
foreign sources. This way invalid unicode is caught early and
decode gets a speedup.

char[] is different because the mutability means it could be made
invalid at any time so we can't rely on it staying valid after
it's been checked but once a string has been confirmed valid
there is no reason to check it for validity ever again.

On 02/08/2014 07:44 PM, Brad Anderson wrote:
> On Saturday, 8 February 2014 at 05:04:35 UTC, Jonathan M Davis
> wrote:
>> I think that that would call for us to have 3 related but distinct
>> functions:
>>
>> 1. decode, which throws on invalid Unicode. We already have this.
>
> I wonder if it'd be too reckless to just make decode for string
> nothrow (we want this function to be as fast as possible) and
> just require that string, by definition, must be valid unicode.
> to!string and company could validate strings as they come in from
> foreign sources. This way invalid unicode is caught early and
> decode gets a speedup.
>
> char[] is different because the mutability means it could be made
> invalid at any time so we can't rely on it staying valid after
> it's been checked but once a string has been confirmed valid
> there is no reason to check it for validity ever again.

"☹"[1..$]

On Saturday, 8 February 2014 at 18:44:38 UTC, Brad Anderson wrote:
> I wonder if it'd be too reckless to just make decode for string
> nothrow (we want this function to be as fast as possible) and
Yes. It shouldn't throw. Never.

> just require that string, by definition, must be valid unicode.
Why?
Replacement of broken code is defined by unicode - we should use it.
Noone prevents you to call isValidUnicode beforehand and handle that sepearately if it returns "false" (I would recomment that only if security is relevant e.g. if you chack a signature or something like that) or search for 0xFFFD in the result string afterwards and throw if you find some (but this is generally no good idea because the replacement characters may have been there even before and were intended).
As default relplacing broken characters is very good. And fast.

On 2/7/2014 6:50 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> The specific problem was that it was possible to provoke hash collisions by
> sending carefully crafted input, causing the hash-tables to degrade to linked
> lists. The small performance penalty of using collision-resistant hashes is
> certainly worth it in this case.

That has nothing to do with needing exceptions in the control flow path (and the performance penalty for using exceptions in this manner is certainly not small).

On 2/7/2014 8:40 AM, Dmitry Olshansky wrote:
> Meh. If exceptions are such a liability we'd better make them (much) faster.

They can be made faster by slowing down non-exception code.

This has been debated at length in the C++ community, and the generally accepted answer is that non-exception code performance is preferred and exception performance is thrown under the bus in order to achieve it.

I think it's quite a reasonable conclusion.

On 2/7/2014 9:06 AM, Dmitry Olshansky wrote:
> Why throwing a single exception is such a big problem?

Because in order to unwind the stack, you need to find the information about the stack layout. This lookup is rather slow. You can make the lookup faster by compromising the function code generation, but this is considered an unacceptable tradeoff.

On 2/7/2014 10:10 AM, Dicebot wrote:
> As I have already mentioned, they don't necessarily need to be. But that may
> require tweaking language so that pre-allocated exception usage becomes reliable
> and I don't see tools right now that allow to express neseccary semantics (can't
> store reference to instance without deep copy)

It is NOT the allocation that's the issue. C++ code has the same issue. It's the exception handling table lookup.

On 2/7/2014 10:54 AM, Sean Kelly wrote:
> But yeah, it's the allocations that are a problem in this case,

Code can always pre-allocate the exception that is thrown. There's no reason whatsoever that allocation is required at the throw point, nor is there any reason the thrown exception has to be newly allocated each time.

And, as such, this is entirely a coding issue, not a language or runtime one.

09-Feb-2014 02:03, Walter Bright пишет:
> On 2/7/2014 9:06 AM, Dmitry Olshansky wrote:
>> Why throwing a single exception is such a big problem?
>
> Because in order to unwind the stack, you need to find the information
> about the stack layout. This lookup is rather slow. You can make the
> lookup faster by compromising the function code generation, but this is
> considered an unacceptable tradeoff.

A special table lookup can't be slow compared to writing a dummy HTTP 500 response. Just saying. Yes, it's a tad slower then cmp + jz, I do understand that.

Again I'm trying to say that framing stack unwinding as the culprit of vibe.d crawling under bad requests is plain wrong, and that was the focal point of the original argument.

-- 
Dmitry Olshansky

On 2/7/2014 11:53 AM, Jonathan M Davis wrote:
> or to avoid allocating them

Grep for 'throw' in std.datetime shows that every throw is actually:

    throw new ...

and an example:

    throw new DateTimeException("SYSTEMTIME cannot hold dates prior to the year 1601.");

There is no requirement that the new is done there. You can preallocate the DateTimeException statically, and simply keep rethrowing the same exception instance.

I.e. the allocation issue is a coding style issue, not a language problem.