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