Jump to page: 1 2 3
Thread overview
The cast(signed), cast(unsigned) feature proposal
Jun 07, 2013
Mrzlga
Jun 07, 2013
Adam D. Ruppe
Jun 07, 2013
Mrzlga
Jun 07, 2013
Jesse Phillips
Jun 07, 2013
Idan Arye
Jun 07, 2013
Idan Arye
Jun 08, 2013
Mrzlga
Jun 08, 2013
Mrzlga
Jun 08, 2013
Timothee Cour
Jun 08, 2013
Mrzlga
Jun 08, 2013
Timothee Cour
Jun 08, 2013
Mrzlga
Jun 08, 2013
Timothee Cour
Jun 08, 2013
Idan Arye
Jun 08, 2013
Mrzlga
Jun 08, 2013
Mrzlga
Jun 08, 2013
Timothee Cour
Jun 08, 2013
timotheecour
Jun 08, 2013
Idan Arye
Jun 08, 2013
Mrzlga
Jun 08, 2013
Walter Bright
Jun 07, 2013
Mrzlga
Jun 08, 2013
Marco Leise
Jun 07, 2013
monarch_dodra
Jun 07, 2013
monarch_dodra
Jun 08, 2013
deadalnix
June 07, 2013
Hi guys,

This is a small feature proposal.
Please consider to add these to the language:

    cast(signed)
    cast(unsigned)


Motivation:

- To remove the need to write "cast(ulong) x" and repeat the underlying type, which is the same motivation as cast(const), cast(immutable), cast(shared)

- Reduce the strain of writing signed/unsigned conversions, so that making signed/unsigned conversions a compilation error is more palatable.

- Works as a new feature: if we have created a function or template which uses Concepts to accept just a signed number, we can use cast(unsigned) to generically cast any type X to the unsigned version.


Positives:

- cast(signed) is easy to type.

- cast(signed) is easy to see -- Scanning over the code with your eyes, we can see that the only intention was to make a cast about the signedness, but not about anything else.

- Works within the system of grepping for all casts.

- Works in the spirit of 'auto'.

- Consistent with cast(const), cast(immutable), cast(shared).


Downsides:

- Adds two keywords to the language.
    > They aren't the worst keywords, considering that C has them.

- 'unsigned already means something in C, let's not change how it works'

- Writing "cast(unsigned) x" is actually more text than "cast(ulong) x"
    > True, but the cast(unsigned) expresses the intention


Possible arguments against:

- The idea of 'no casts should be generic'

- Use the library for it and instead make signed(x), unsigned(x) templates.

    > Downsides to this solution: User can't easily grep for 'cast' and find the 'unsigned(x)' template. It should be consistently greppable in the exact same way as other casts. Because it is a cast, so don't hide it.


That's it!

Thanks for your consideration :)
June 07, 2013
On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
> - Use the library for it and instead make signed(x), unsigned(x) templates.

I think this is a really strong counterargument and one I'd like to see done, along with other kinds of casts in the library.

>     > Downsides to this solution: User can't easily grep for 'cast' and find the 'unsigned(x)' template. It should be consistently greppable in the exact same way as other casts. Because it is a cast, so don't hide it.

I would name it cast_to_unsigned or signed_cast or something like that. Then the word "cast" is still there.

Most of phobos uses camelCase so underscores might be weird, but it is a cast, it is supposed to be a little weird, and besides, I can't get C++'s various_casts out of my mind.
June 07, 2013
On 6/7/13 4:52 PM, Mrzlga wrote:
> Hi guys,
>
> This is a small feature proposal.
> Please consider to add these to the language:
>
> cast(signed)
> cast(unsigned)

http://dlang.org/phobos/std_traits.html#.unsigned

We should prolly add signed() as well. Could you please author an enhancement request (and at best a pull request too)?


Thanks,

Andrei

June 07, 2013
On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
> That's it!
>
> Thanks for your consideration :)

FWI, you can use std.trait's Signed and Unsigned as a partial alternative.
http://dlang.org/phobos/std_traits.html#.Signed

IMO, not quite as elegant. I support this syntax. It's natural, and I *think* the "keywords" are reserved anyways, so that shouldn't be a problem anyways. We already have "cast(const)" anyways, so cast(signed) is (imo) only natural. I'd almost expect it to work.


I think this isn't the first time it has been brought up either. Unless I'm mistaken, user Bearophile has opened a request for this. Not 100% sure though. Gonna look for it.
June 07, 2013
On Friday, 7 June 2013 at 21:04:40 UTC, monarch_dodra wrote:
> On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
>> That's it!
>>
>> Thanks for your consideration :)
>
> FWI, you can use std.trait's Signed and Unsigned as a partial alternative.
> http://dlang.org/phobos/std_traits.html#.Signed
>
> IMO, not quite as elegant. I support this syntax. It's natural, and I *think* the "keywords" are reserved anyways, so that shouldn't be a problem anyways. We already have "cast(const)" anyways, so cast(signed) is (imo) only natural. I'd almost expect it to work.
>
>
> I think this isn't the first time it has been brought up either. Unless I'm mistaken, user Bearophile has opened a request for this. Not 100% sure though. Gonna look for it.

EDIT: Couldn't find it. Must have been my imagination. Didn't realize we had "signed" too (as opposed to "Signed"), so I'm not sure how useful that would be actually.

I still find it idiomatic though.
June 07, 2013
A reason for cast(signed) is to discourage the user from writing:

    cast(int) x;

Because we can't grep for the word "signed",
We have to search for "cast( )" only!

    cast(int) x    // hides the intention, hard to search for!

Yet we can easily grep for:

    cast(signed)
June 07, 2013
Andrei, what do you think about the unsigned(x) not showing up on greps for 'cast'? No problem? Is the grep irrelevant? Not all casts should be marked as a cast?

People told me the grepping was important, so I tried to work their idea in.


I understand, you can still search for:
"signed("                     // signed or unsigned
"cast(u"                      // unsigned
"cast( ... every type ... )"  // trying to find signed conversions


But I was trying to make the thing more predictable altogether.
June 07, 2013
On Friday, 7 June 2013 at 21:34:00 UTC, Mrzlga wrote:
> A reason for cast(signed) is to discourage the user from writing:
>
>     cast(int) x;
>
> Because we can't grep for the word "signed",
> We have to search for "cast( )" only!
>
>     cast(int) x    // hides the intention, hard to search for!
>
> Yet we can easily grep for:
>
>     cast(signed)

Not convenient, but:

    cast(Signed!(typeof(x))
June 07, 2013
On Friday, 7 June 2013 at 21:42:05 UTC, Jesse Phillips wrote:
> On Friday, 7 June 2013 at 21:34:00 UTC, Mrzlga wrote:
>> A reason for cast(signed) is to discourage the user from writing:
>>
>>    cast(int) x;
>>
>> Because we can't grep for the word "signed",
>> We have to search for "cast( )" only!
>>
>>    cast(int) x    // hides the intention, hard to search for!
>>
>> Yet we can easily grep for:
>>
>>    cast(signed)
>
> Not convenient, but:
>
>     cast(Signed!(typeof(x))

How about this: if `Foo` is a template with a single type parameter that returns a type, writing `cast(Foo)bar` will be parsed as `cast(Foo!(typeof(bar))bar`.

This will allow as to write `cast(Signed)x` - no need for extra keywords - and it will also allow us to write more generic things, like `cast(Nullable)(x)` will return a `typeof(x)` `Nullable` that holds the value of `x` - whatever that value may be.

I've written a simple function that does that:

    auto Cast(alias Template,T)(T source){
        return cast(Template!T)(source);
    }

And it works, but not as good as the template solution since `typeof(Cast!Nullable(0))` returns `Template!(int)` instead of `Nullable!(int)`.
June 07, 2013
On Friday, 7 June 2013 at 22:05:46 UTC, Idan Arye wrote:
> but not as good as the template solution

Should be "not as good as the syntactic sugar solution"
« First   ‹ Prev
1 2 3