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

Timothee Cour thelastmammoth at gmail.com
Fri Jun 7 19:20:47 PDT 2013


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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130607/8c851cf9/attachment-0001.html>


More information about the Digitalmars-d mailing list