Thread overview | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 07, 2013 The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mrzlga | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mrzlga | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mrzlga | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarch_dodra | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mrzlga | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | 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 Re: The cast(signed), cast(unsigned) feature proposal | ||||
---|---|---|---|---|
| ||||
Posted in reply to Idan Arye | 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"
|
Copyright © 1999-2021 by the D Language Foundation