The cast(signed), cast(unsigned) feature proposal

timotheecour timothee.cour2 at gmail.com
Fri Jun 7 19:23:40 PDT 2013


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 at 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.


More information about the Digitalmars-d mailing list