Menu
Search

Forums

Forum Index

2 days ago
Gravatar of Paul BackusPosted by Paul Backus
in reply to Walter Bright		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Walter Bright


Reply
On Monday, 20 January 2025 at 22:55:29 UTC, Walter Bright wrote:
> On 1/19/2025 9:33 AM, Paul Backus wrote:
>> Why not just add a simple `reinterpretCast!T` helper function to Phobos or druntime?
>
> Great question.
>
> `reinterpretcast!T` is just ugly. I never liked it in C++. `cast(ref T)`, on the other hand, looks nice.

Would you be open to using a helper function if it had a shorter, less ugly name?
2 days ago
Gravatar of Andrea FontanaPosted by Andrea Fontana
in reply to Paul Backus		Reply
Andrea Fontana
Gravatar of Andrea Fontana
Posted in reply to Paul Backus


Reply
On Tuesday, 21 January 2025 at 03:43:02 UTC, Paul Backus wrote:
> On Monday, 20 January 2025 at 22:55:29 UTC, Walter Bright wrote:
>> On 1/19/2025 9:33 AM, Paul Backus wrote:
>>> Why not just add a simple `reinterpretCast!T` helper function to Phobos or druntime?
>>
>> Great question.
>>
>> `reinterpretcast!T` is just ugly. I never liked it in C++. `cast(ref T)`, on the other hand, looks nice.
>
> Would you be open to using a helper function if it had a shorter, less ugly name?

ptrCast!T
2 days ago
Gravatar of ryuukk_Posted by ryuukk_
in reply to Paul Backus		Reply
ryuukk_
Gravatar of ryuukk_
Posted in reply to Paul Backus


Reply

On Tuesday, 21 January 2025 at 03:43:02 UTC, Paul Backus wrote:

>

On Monday, 20 January 2025 at 22:55:29 UTC, Walter Bright wrote:

>

On 1/19/2025 9:33 AM, Paul Backus wrote:

>

Why not just add a simple reinterpretCast!T helper function to Phobos or druntime?

Great question.

reinterpretcast!T is just ugly. I never liked it in C++. cast(ref T), on the other hand, looks nice.

Would you be open to using a helper function if it had a shorter, less ugly name?

please stop trying to kill D improvement proposals by suggesting Yet Another Template

nobody, literally, nobody ever thought of using a template TO CAST, this is ridiculous, stop

Makes debugging poor

Makes compile speed poor

Makes error messages poor

There should be a rule to ban the word "template" from DIPs discussions

Focus on wether or not it is a good idea, stop the bikeshedding, it's time to accelerate, i swear, people are ignored D when they discuss better C languages

Even the mainstream media ignores D

https://x.com/lexfridman/status/1878871091667448123

I know i am annoying, not all my suggestions are good, but c'mon, a template to ask..

RandomPerson: sir, how i i cast in D?

DMaintainerOf10years: you have to `import std.meta.cast`, then you call this template `castPleaseIntoThisT!(T)`

RandomPerson: wow, this is the best language ever

RandomPerson has left the chat.
2 days ago
Gravatar of IchorDevPosted by IchorDev
in reply to Walter Bright		Reply
IchorDev
Gravatar of IchorDev
Posted in reply to Walter Bright


Reply

On Monday, 20 January 2025 at 23:09:24 UTC, Walter Bright wrote:

>

I haven't really thought about that. But this also works and is simpler and easier to read:

void[] foo = cast(void[])((&bar)[0 .. 1]);

Doesn’t this incur a runtime bounds check? Also does this work with non-void slices?

>

That wouldn't be good because it would stomp on whatever is next in memory.

No, it would allocate new stack memory or use a new register. You’ll assign the expression to something anyway, so it’s like if you declared a default initialised variable and partially overwrote it. I’ve actually needed this pattern quite a lot when interacting with C and often I just have to cast to ubyte[] and write all the lengths manually. Looks ugly.

2 days ago
Gravatar of IchorDevPosted by IchorDev
in reply to Walter Bright		Reply
IchorDev
Gravatar of IchorDev
Posted in reply to Walter Bright


Reply

On Monday, 20 January 2025 at 23:11:46 UTC, Walter Bright wrote:

>

On 1/20/2025 2:07 AM, Juraj wrote:

>

We now have local ref, and that makes this syntax a cognitive burden.

Think of cast(ref int)f as "refer to f as if it were an int" and it will make perfect sense.

I agree that the syntax is confusing.
When I see cast(ref T) I think it’s like __rvalue in reverse: allowing you to forcibly allow ref to bind an rvalue. In fact, I’d prefer that meaning for cast(ref T) (or cast(ref)) since it’s intuitive.
What about cast(in T) instead? As in ‘re-INterpret’. in also doesn’t make sense for local variables, so it actually reads as a different use of the keyword.

2 days ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to IchorDev		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to IchorDev


Reply
On 1/21/2025 1:33 PM, IchorDev wrote:
> On Monday, 20 January 2025 at 23:09:24 UTC, Walter Bright wrote:
>> I haven't really thought about that. But this also works and is simpler and easier to read:
>>
>> ```
>> void[] foo = cast(void[])((&bar)[0 .. 1]);
>> ```
> 
> Doesn’t this incur a runtime bounds check?

No.

> Also does this work with non-void slices?

It is a non-void slice!


>> That wouldn't be good because it would stomp on whatever is next in memory.
> 
> No, it would allocate new stack memory or use a new register.

That could happen, but it is not what happens.

> You’ll assign the expression to something anyway, so it’s like if you declared a default initialised variable and partially overwrote it. I’ve actually needed this pattern quite a lot when interacting with C and often I just have to cast to `ubyte[]` and write all the lengths manually. Looks ugly.

Reading past the end of a memory object could produce a seg fault. Writing is a near certain disaster.
2 days ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to IchorDev		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to IchorDev


Reply
On 1/21/2025 1:47 PM, IchorDev wrote:
> On Monday, 20 January 2025 at 23:11:46 UTC, Walter Bright wrote:
>> Think of `cast(ref int)f` as "refer to `f` as if it were an `int`" and it will make perfect sense.
> 
> I agree that the syntax is confusing.

For a moment, sure. But think of it as I suggested, and it will clear away the confusion.
1 day ago
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to Walter Bright		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to Walter Bright


Reply

On Monday, 20 January 2025 at 23:09:24 UTC, Walter Bright wrote:

>

On 1/20/2025 1:07 AM, IchorDev wrote:

> 
void[] foo = (cast(void*)&bar)[0..bar.sizeof];

I haven't really thought about that. But this also works and is simpler and easier to read:

void[] foo = cast(void[])((&bar)[0 .. 1]);

You don't need the cast even (all arrays implicitly cast to void[])

void[] foo = (&bar)[0 .. 1];

-Steve

1 day ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to Paul Backus		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Paul Backus


Reply
On 1/20/2025 7:43 PM, Paul Backus wrote:
> Would you be open to using a helper function if it had a shorter, less ugly name?

The shorter the name, and the less ugly it is, the more it risks breaking code. Overloading keywords is commonplace in languages, and D, to avoid that problem.

Consider the builtin associative arrays. These have been a big success. All attempts at making it a template foundered on it being less convenient to use.

One of the problems of relying on templates for basic things is they aren't in the language specification, so people don't realize they are there.

P.S. AliasSeq also impairs the use of tuples.
1 day ago
Gravatar of IchorDevPosted by IchorDev
in reply to Walter Bright		Reply
IchorDev
Gravatar of IchorDev
Posted in reply to Walter Bright


Reply

On Wednesday, 22 January 2025 at 01:01:58 UTC, Walter Bright wrote:

>

It is a non-void slice!

I meant doing this:
T[] foo = cast(T[])((&bar)[0 .. 1]);
Where bar is (e.g.) int[].

>

Reading past the end of a memory object could produce a seg fault. Writing is a near certain disaster.

I mean that a reinterpret cast from uint to long would lower to this:

uint x;
long y;
(cast(ubyte[8])long)[0..4] = (cast(ubyte[4])x)[];

Also you missed my alternative syntax suggestion:

>

What about cast(in T) instead? As in ‘re-INterpret’. in also doesn’t make sense for local variables, and already has multiple meanings, so it’s easier to see that the keyword has a different meaning for cast(in T).

I’m against this change but only because the proposed syntax is adding the first ever exception to ref’s usual meaning. cast(ref T) should be reserved for a feature consistent with the existing meaning of ref.

« First   ‹ Prev
1 2 3
Next ›   Last »