On Friday, September 21, 2012 11:00:31 monarch_dodra wrote:
> What do you (you two) think of my proposition for a
> "std.strictascii" module?

I don't think that it's at all worth it. It's just duplicate functionality in order to avoid a cast.

- Jonathan M Davis

On Friday, 21 September 2012 at 10:23:39 UTC, Jonathan M Davis wrote:
> On Friday, September 21, 2012 11:00:31 monarch_dodra wrote:
>> What do you (you two) think of my proposition for a
>> "std.strictascii" module?
>
> I don't think that it's at all worth it. It's just duplicate functionality in
> order to avoid a cast.

(and contract)

>
> - Jonathan M Davis

Somehow, I expected that reply, but I had to ask anyways :D

Thanks.

On Friday, September 21, 2012 12:38:07 monarch_dodra wrote:
> On Friday, 21 September 2012 at 10:23:39 UTC, Jonathan M Davis
> 
> wrote:
> > On Friday, September 21, 2012 11:00:31 monarch_dodra wrote:
> >> What do you (you two) think of my proposition for a
> >> "std.strictascii" module?
> > 
> > I don't think that it's at all worth it. It's just duplicate
> > functionality in
> > order to avoid a cast.
> 
> (and contract)

If that's what you want, it's easy enough to create a helper function which you use instead of a cast which does the contract check as well. e.g.

char toChar(dchar c)
{
    assert(isAscii(c));
    return cast(char)c;
}

foreach(ref char c; str)
    c = toChar(std.ascii.toLower(c));

It should be completely optimized out with -release and -inline.

- Jonathan M Davis

On Friday, 21 September 2012 at 10:45:42 UTC, Jonathan M Davis wrote:
> On Friday, September 21, 2012 12:38:07 monarch_dodra wrote:
>> On Friday, 21 September 2012 at 10:23:39 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Friday, September 21, 2012 11:00:31 monarch_dodra wrote:
>> >> What do you (you two) think of my proposition for a
>> >> "std.strictascii" module?
>> > 
>> > I don't think that it's at all worth it. It's just duplicate
>> > functionality in
>> > order to avoid a cast.
>> 
>> (and contract)
>
> If that's what you want, it's easy enough to create a helper function which
> you use instead of a cast which does the contract check as well. e.g.
>
> char toChar(dchar c)
> {
>     assert(isAscii(c));
>     return cast(char)c;
> }
>
> foreach(ref char c; str)
>     c = toChar(std.ascii.toLower(c));
>
> It should be completely optimized out with -release and -inline.
>
> - Jonathan M Davis

That's a real good idea. Also, I find it is these kinds of situations where UFCS really shines (IMO):

    foreach(i, c; s1)
        cs[i] = c.toUpper().toChar();

I love this syntax.

Related, could "toChar" be considered for inclusion? I think it would be a convenient tool for validation.

/*
 * Casts dchar to a char.
 *
 * Preconditions:
 *   $(D c) must be representable in a single char.
 */
char toChar(dchar c)
{
    assert(c < 256, "toChar: Input too large for char");
    return cast(char)c;
}

That said, if we go that way, we might as well just have a more generic safeCast in std.conv or something:

T safeCast(T, U)(U i)
    if(isBasicType!T && isBasicType!U)
{
    assert(cast(T)i == i, "safeCast: Cast failed");
    return cast(T)i;
}

    foreach(i, c; s1)
        cs[i] = c.toUpper().safeCast!char();

Hum... yeah... I don't know...

I seem to be typing faster than I can really think of the consequences of such a function.

On Friday, September 21, 2012 13:18:01 monarch_dodra wrote:
> Related, could "toChar" be considered for inclusion? I think it would be a convenient tool for validation.

I certainly would be against adding it. I think that it's a relatively uncommon use case and considering how easy it is to just write the function yourself, the functionality gain is minimal. I just don't think that it carries it's weight as far as the standard library goes. But I don't know how others like Andrei would feel.

> That said, if we go that way, we might as well just have a more generic safeCast in std.conv or something:

You're basically asking for a version of std.conv.to which uses assertions instead of exceptions.

- Jonathan M Davis

On Friday, 21 September 2012 at 11:25:54 UTC, Jonathan M Davis wrote:
> On Friday, September 21, 2012 13:18:01 monarch_dodra wrote:
>> Related, could "toChar" be considered for inclusion? I think it
>> would be a convenient tool for validation.
>
> I certainly would be against adding it. I think that it's a relatively
> uncommon use case and considering how easy it is to just write the function
> yourself, the functionality gain is minimal. I just don't think that it
> carries it's weight as far as the standard library goes. But I don't know how
> others like Andrei would feel.
>
>> That said, if we go that way, we might as well just have a more
>> generic safeCast in std.conv or something:
>
> You're basically asking for a version of std.conv.to which uses assertions
> instead of exceptions.
>
> - Jonathan M Davis

I know my ideas usually get shot down, but I usually learn a LOT from your answers, so sorry for insisting.

I did not know conv's to did cast validation. In my defense, the doc is actually missing:

http://dlang.org/phobos/std_conv.html

I made a doc pull request so that it would appear.

https://github.com/D-Programming-Language/phobos/pull/811

On Friday, September 21, 2012 14:10:25 monarch_dodra wrote:
> I did not know conv's to did cast validation.

For conversions which can be done with both casting and std.conv.to, std.conv.to does runtime checks wherever a narrowing conversion would take place and throws if the conversion would lose precision.

- Jonathan M Davis

On 20/09/12 18:57, Jonathan M Davis wrote:
> On Thursday, September 20, 2012 18:35:21 bearophile wrote:
>> monarch_dodra:
>>> It's not, it only *operates* on ASCII, but non ascii is still a
>>
>>> legal arg:
>> Then maybe std.ascii.toLower needs a pre-condition that
>> constraints it to just ASCII inputs, so it's free to return a
>> char.
>
> Goodness no.
>
> 1. Operating on a char is almost always the wrong thing to do. If you really
> want to do that, then cast. It should _not_ be encouraged.
>
> 2. It would be disastrous if std.ascii's funtions didn't work on unicode.
> Right now, you can use them with ranges on strings which are unicode, which
> can be very useful.
> I grant you that that's more obvious with something like
> isDigit than toLower, but regardless, std.ascii is designed such that its
> functions will all operate on unicode strings. It just doesn't alter unicode
> characters and returns false for them with any of the query functions.

Are there any use cases of toLower() on non-ASCII strings?
Seriously? I think it's _always_ a bug.

At the very least that function should have a name like toLowerIgnoringNonAscii() to indicate that it is performing a really, really foul operation.

The fact that toLower("Ü") doesn't generate an error, but doesn't return "ü" is a wrong-code bug IMHO. It isn't any better than if it returned a random garbage character (eg, it's OK in my opinion for ASCII toLower to consider only the lower 7 bits).

OTOH I can see some value in a cased ASCII vs unicode comparison.
ie, given an ASCII string and a unicode string, do a case-insensitive comparison, eg look for
"<HTML>" inside "öähaøſ€đ@<html>ſŋħŋ€ł¶"