On 11/19/13 7:45 AM, Jacob Carlborg wrote:
> On 2013-11-19 16:01, Andrei Alexandrescu wrote:
>
>> That doesn't have an empty line after each statement.
>
> If an expression or another statement follows, then yes.

You're not operating with the correct definitions of "expression" and "statement".

Andrei

On 2013-11-19 16:56, Andrei Alexandrescu wrote:

> You're not operating with the correct definitions of "expression" and
> "statement".

I would consider this a statement: https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L285..L286

And this an expression: https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L288

The first would be an if-statement [1] and the second would be an assign expression [2]. Am I wrong?

[1] http://dlang.org/statement.html#IfStatement
[2] http://dlang.org/expression.html#AssignExpression

-- 
/Jacob Carlborg

On Tue, 19 Nov 2013 03:29:48 -0000, Michel Fortin <michel.fortin@michelf.ca> wrote:

> On 2013-11-18 23:42:13 +0000, "Jonathan M Davis" <jmdavisProg@gmx.com> said:
>
>> I understand this. The problem is that in some cases, in order to do the
>> check, you have to do all of the work that the function you're trying to
>> protect bad input from has to do anyway - even without it asserting anything.
>> So, having a separate function do the checking would just be extra overhead.
>
> Very true.
>
> I'll just point out now that you could actually have only one function that does one or the other or both depending on template parameters. One template parameter is the output sink, which could be a dummy type that does nothing or an actual type that saves the data somewhere. Another parameter is the error handler, which can be a dummy type that does nothing, or it could assert or throw when an error is found. Let the optimizer remove the do-nothing code paths that will result.
>
> Now, I really have no idea but that could be overkill in this situation.

Why use templates at all?  Lets just keep it simple..

You just write /the/ one internal conversion/check function (for each case) such that it returns a boolean success status, then.. in release mode you call it and throw on false/failure, and in debug mode you call it in and assert on false/failure.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

"Jacob Carlborg"  wrote:
> I would say that it would be quite cumbersome and verbose to for the user to constantly validate the input.

If the "user level" validation fails, shall we throw or assert or...?

-- 
Jouko


---
avast! Antivirus käynnissä, joten tässä sähköpostiviestissä ei ole viruksia tai haittaohjelmia.
http://www.avast.com

On Tuesday, 19 November 2013 at 16:07:17 UTC, Jacob Carlborg wrote:
> On 2013-11-19 16:56, Andrei Alexandrescu wrote:
>
>> You're not operating with the correct definitions of "expression" and
>> "statement".
>
> I would consider this a statement: https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L285..L286
>
> And this an expression: https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L288

http://dlang.org/statement.html#ExpressionStatement

David

On 11/19/13 8:07 AM, Jacob Carlborg wrote:
> On 2013-11-19 16:56, Andrei Alexandrescu wrote:
>
>> You're not operating with the correct definitions of "expression" and
>> "statement".
>
> I would consider this a statement:
> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L285..L286

Sure is.

> And this an expression:
> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L288

That's not an expression, it's a statement - more precisely an expression statement. (The semicolon makes it so.) By the rules you incorrectly stated, there should be an empty line after it.

I'll allow myself a piece of advice - the density of e.g. https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251 is low enough to make it career limiting. You'd do good to change your style.


Andrei

On Tuesday, 19 November 2013 at 18:29:57 UTC, Andrei Alexandrescu wrote:
> I'll allow myself a piece of advice - the density of e.g. https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251 is low enough to make it career limiting.

Doesn't look *that* sparse to me... I think the 8-space indentation give a false perspective. E.g. this is actually 1 line longer, but looks denser:

package string translateFunction (string result, string name, Parameter[] parameters, bool variadic, String context)
{
    context ~= result ~ ' ' ~ name ~ " (";

    string[] params;
    params.reserve(parameters.length);

    foreach (param ; parameters)
    {
        string p;

        version(D1)
        {
            p ~= param.type;
        }
        else
        {
            if (param.isConst)
            {
                p ~= "const(" ~ param.type; ~ ')';
            }
            else
            {
                p ~= param.type;
            }
        }
	
        if (param.name.any)
        {
            p ~= " " ~ translateIdentifier(param.name);
        }
        params ~= p;
    }

    if (variadic)
    {
        params ~= "...";
    }

    context ~= params.join(", ") ~ ')';

    return context.data;
}

On Tuesday, November 19, 2013 16:48:30 Dmitry Olshansky wrote:
> It's also interesting to see that some primitives are better be designed
> to work with untrusted input see utf.decode.
> While others are designed not. What I mean by _designed_ is that
> encountering wrong inputs in a correct program is unavoidable and to be
> expected. Also (2) and (3) can be constructed on top of (1) by widening
> the interface.
> 
> Compare hypothetical:
> Date parseDate(string str);
> vs:
> Date date(Year year, Month month, Day day);
> 
> The first better be designed to scrub input, while the second is
> designed to accept verified values (hence Year, Month and not naked ints).

True, though there can still be invalid days depending on the month and year, so it's not the case that there can't be bad input even if you no casting to Year, Month, or Day was involved. It's one that I debated on and end up going with exceptions, because it was consistent with everything else in std.datetime to do so, but it could also be argued that asserting would have been better in this case. In contrast, as you indicated, parsing a string for a date is clearly a case where exceptions are better.

- Jonathan M Davis

On 2013-11-19 18:59, David Nadlinger wrote:

> http://dlang.org/statement.html#ExpressionStatement

Ok, I didn't know that.

-- 
/Jacob Carlborg

On 2013-11-19 19:29, Andrei Alexandrescu wrote:

> That's not an expression, it's a statement - more precisely an
> expression statement. (The semicolon makes it so.) By the rules you
> incorrectly stated, there should be an empty line after it.

I'm sorry for not know every minor detail of the language.

> I'll allow myself a piece of advice - the density of e.g.
> https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L251
> is low enough to make it career limiting. You'd do good to change your
> style.

Are you serious? Anyone caring about that doesn't know what he/she is doing.

-- 
/Jacob Carlborg