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 harder with language solution.
>
> On Fri, Jun 7, 2013 at 6:53 PM, Mrzlga <bulletproofchest@gmail.com> 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) ?
>>
>> And have everyone be consistent about it?
>>
>> Remove the cast() ones from the language?
>>
>
> 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.
>
>
>> And what about variations, 'shared const', 'inout shared', etc?
>>
>
> it's trivial to add to my code a.Cast!"shared const" or a.Cast!SharedConst,
> etc, as well as more complex ones.
>
>
>> There are some things that should be available to the language, even when
>> no modules are imported. I think dealing with the basic type system is like
>> that.
>>
>
> Not if the syntax sugar provided by the language is no simple than that
> provided by library solution. I've argued library solution is more
> consistent with UFCS (see my code).

not to mention its much harder and bug-prone 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.

> 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 can simultaneously try to not-suggest deprecating cast() shortcuts, and do-suggest there's no need to extend the language as it can be done in library code, while suggestiing duplicating cast() shortcuts. Your point would make sense if you were trying to get rid of the shortcuts. Otherwise you should argue for signed(x) / unsigned(x)

Make it consistent.

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 better; I doubt you're using cast() in all your modules anyways.

However, I very much do support language syntax sugar when it provides advantages over a library solution:

* tuples (see DIP),
* named parameter argument (see threads)
* and even to some extent := (your suggestion!)

On Fri, Jun 7, 2013 at 7:24 PM, Mrzlga <bulletproofchest@gmail.com> wrote:

> 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 can simultaneously try to not-suggest deprecating cast()
> shortcuts, and do-suggest there's no need to extend the language as it can
> be done in library code, while suggestiing duplicating cast() shortcuts.
> Your point would make sense if you were trying to get rid of the shortcuts.
> Otherwise you should argue for signed(x) / unsigned(x)
>
> Make it consistent.
>

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 everything" if there was no price to it.

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)`?

On 6/7/2013 2:33 PM, Mrzlga wrote:
> Yet we can easily grep for:
>      cast(signed)

Not/*"*/"*/that
easy

> 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't want to suggest cast(int) should not work, but rather to think of a solution for better documentation in the code, and to encourage people to write:
    cast(signed) // when they're casting unsigned->signed
    cast(int)    // when they're casting short->int

- I still feel slightly uneasy about the previous point. What I mentioned about cast(signed int) was a form of brainstorming. I wanted to try to give some consideration to people who'd want the destination datatype to be explicit, as it says something about the destination range. However, the fact that we must be careful of the range is already implied by cast(signed) and cast(unsigned).

- I like how cast(const) uses the lowercase const and the same const keyword. There's a nice consistency about that. So I don't want them in the library.

- Cast operations should be available without module imports.

- I would use the cast(signed) and feel comfortable.

- I could use the signed(x) and enjoy it! cast(signed) is not a super important thing like the :=

- I think *your* idea was good and possibly better than mine, as it allows library authors to create new numerical types that support signed/unsigned casting, and yet still access it via cast(signed) if 'signed' was the template.

- I'm not sure if Walter & Andrei would want cast(ToWorkWithTheTemplates).


Regards,
z

Am Fri, 07 Jun 2013 17:03:47 -0400
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> 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

That made me scratch my head again. I thought
std.traits contains non-modifying queries into the type system
and std.typecons contains the _actions_ for type system
trickery.
In any case I wouldn't have searched std.traits for a function
that gets stuff done.

On the topic, I think that D's cast() does too many things in one. You can _accidentally_ cast away immutable for example and run into undefined behavior as per the language specs. At first I liked how D got rid of C's different casts, but on the long run it is too pragmatic for my taste.

-- 
Marco

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 !