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.
This !
Am Fri, 07 Jun 2013 17:03:47 -0400
schrieb Andrei Alexandrescu :
> 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#.unsigne
So, let me get this straight:
* You don't want `cast(signed)`, because of the range
difference between the types.
* You want `cast(signed int)` but not as syntactic salt -
which means you still want `cast(int)` to work.
How about `cast(/*signed*/ int)`?
- I do want cast(signed)
- I don'
On 6/7/2013 2:33 PM, Mrzlga wrote:
Yet we can easily grep for:
cast(signed)
Not/*"*/"*/that
easy
On Saturday, 8 June 2013 at 01:58:46 UTC, Mrzlga wrote:
So, you want a syntactic salt that will force people to write
No, no, I don't actually want the salt. I hoped I had indicated
that in my message.
It was only for your consideration about cast(int), how it
would be nice to "indicate eve
the point is to avoid breaking code.
Since no-one can possibly use cast(unsigned) currently, introducing Cast
and recommending using Cast instead of cast() will not break any code and
provide room for library based cast extensions.
The smaller the symbols in scope and the shorter the syntax the be
not suggesting deprecating cast(), just suggesting there's no
need to
extend the language as it can be done in library code,
advantageously. It's
trivially extensible as I wrote it. However, any language
extension has to
be re-implemented by each compiler implementation.
I don't think you ca
On Saturday, 8 June 2013 at 02:21:01 UTC, Timothee Cour wrote:
not to mention its much harder to implement in language,
whereas its
trivial in the library. Also, it makes instrumentation easier,
if one wants
to add a callback/logging/breakpoint for a particular cast
operation. Seems
much harde
not to mention its much harder to implement in language, whereas its
trivial in the library. Also, it makes instrumentation easier, if one wants
to add a callback/logging/breakpoint for a particular cast operation. Seems
much harder with language solution.
On Fri, Jun 7, 2013 at 6:53 PM, Mrzlga w
I don't know the story of how D resolved to not provide 'ulong'
and 'unsigned long' as equivalent, but I do understand the
motivation to keep things short and standard, with
1-word-per-basic-type.
I should say one thing though,
In C / C++:
unsigned x = f(); // this was traumatic. "unsigned
On Fri, Jun 7, 2013 at 6:53 PM, Mrzlga wrote:
> Timothy,
>
> How do you get everyone to use:
> a.Cast!Signed
> a.Cast!Unsigned
> a.Cast!Const
> a.Cast!Immutable
> a.Cast!Shared
>
> And to stop using:
> cast(const)
> cast(immutable)
> cast(shared)
> cast(inout)
So, you want a syntactic salt that will force people to write
No, no, I don't actually want the salt. I hoped I had indicated
that in my message.
It was only for your consideration about cast(int), how it would
be nice to "indicate everything" if there was no price to it.
Timothy,
How do you get everyone to use:
a.Cast!Signed
a.Cast!Unsigned
a.Cast!Const
a.Cast!Immutable
a.Cast!Shared
And to stop using:
cast(const)
cast(immutable)
cast(shared)
cast(inout) ?
And have everyone be consistent about it?
Remove the cast() ones from
On Saturday, 8 June 2013 at 00:43:28 UTC, Mrzlga wrote:
"doing nothing but converting unsigned->signed" is a dubious
statement.
They are still screwing with the range, they are not just
"doing nothing but converting unsigned->signed".
And 'int' says something about the outcome.
So I am reall
I'm against it since we can do it better in library with same efficiency
and better UFCS syntax: see
https://github.com/timotheecour/dtools/blob/master/dtools/util/cast_funs.d
to test it, nothing to install, just type: rdmd --main -unittest
dtools/all.d
here's the unittest:
version(unittest
"doing nothing but converting unsigned->signed" is a dubious
statement.
They are still screwing with the range, they are not just "doing
nothing but converting unsigned->signed".
And 'int' says something about the outcome.
So I am really asking for:
cast(signed int) x; // make them poor pr
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`.
My proposal has a bad thing about it:
The 'unsigned' and 'signed' keywords can't be as easily extended
the way that an signed(x) templ
On 6/7/13 5:41 PM, Mrzlga wrote:
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
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
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"
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 ca
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("
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)
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
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: Us
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
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
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)
28 matches
Mail list logo
