Menu
Search

Forums

Forum Index

February 29
Gravatar of Walter BrightPosted by Walter Bright
in reply to Dakota		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Dakota


Reply
On 2/27/2024 9:26 PM, Dakota wrote:
> It is not impractical to add so much `cast(Message*)` into D code.

Hmm, interesting approach!
February 29
Gravatar of Walter BrightPosted by Walter Bright
in reply to Walter Bright		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Walter Bright


Reply
On 2/29/2024 11:22 AM, Walter Bright wrote:
> On 2/27/2024 9:26 PM, Dakota wrote:
>> It is not impractical to add so much `cast(Message*)` into D code.
> 
> Hmm, interesting approach!
> 

I'm wondering if you could try adding this:

    #define const

and see how far that goes!
March 01
Gravatar of DakotaPosted by Dakota
in reply to Walter Bright		Reply
Dakota
Gravatar of Dakota
Posted in reply to Walter Bright


Reply

On Thursday, 29 February 2024 at 19:25:05 UTC, Walter Bright wrote:

>

On 2/29/2024 11:22 AM, Walter Bright wrote:

>

On 2/27/2024 9:26 PM, Dakota wrote:

>

It is not impractical to add so much cast(Message*) into D code.

Hmm, interesting approach!

I'm wondering if you could try adding this:

#define const

and see how far that goes!

On Thursday, 29 February 2024 at 19:25:05 UTC, Walter Bright wrote:

>

On 2/29/2024 11:22 AM, Walter Bright wrote:

>

On 2/27/2024 9:26 PM, Dakota wrote:

>

It is not impractical to add so much cast(Message*) into D code.

Hmm, interesting approach!

I'm wondering if you could try adding this:

#define const

and see how far that goes!

This cloud work but I don't want go this way. (loss const prone to errors in my d code, because there is a lot property read should return const, and the returned const need pass into other function chain. remove const is not a solution)

I suggestion add a dmd flags to change the behavior, like --importC-const-pointer=. so the user can choice what kind behavior they want.

some project use transitive const in C, so they can work with this new options.

One more options is translate it into a user-defined template, this is more flexible. user can return diff result base on the name. for example:

typedef struct Message Message;
int tryEncode(const Message* msg);

=>

struct Message;
int tryEncode(importConstPointer!(Message)* msg);
March 01
Gravatar of ryuukk_Posted by ryuukk_
in reply to Dakota		Reply
ryuukk_
Gravatar of ryuukk_
Posted in reply to Dakota


Reply

On Friday, 1 March 2024 at 09:52:34 UTC, Dakota wrote:

>

On Thursday, 29 February 2024 at 19:25:05 UTC, Walter Bright wrote:

>

On 2/29/2024 11:22 AM, Walter Bright wrote:

>

On 2/27/2024 9:26 PM, Dakota wrote:

>

It is not impractical to add so much cast(Message*) into D code.

Hmm, interesting approach!

I'm wondering if you could try adding this:

#define const

and see how far that goes!

On Thursday, 29 February 2024 at 19:25:05 UTC, Walter Bright wrote:

>

On 2/29/2024 11:22 AM, Walter Bright wrote:

>

On 2/27/2024 9:26 PM, Dakota wrote:

>

It is not impractical to add so much cast(Message*) into D code.

Hmm, interesting approach!

I'm wondering if you could try adding this:

#define const

and see how far that goes!

This cloud work but I don't want go this way. (loss const prone to errors in my d code, because there is a lot property read should return const, and the returned const need pass into other function chain. remove const is not a solution)

I suggestion add a dmd flags to change the behavior, like --importC-const-pointer=. so the user can choice what kind behavior they want.

some project use transitive const in C, so they can work with this new options.

One more options is translate it into a user-defined template, this is more flexible. user can return diff result base on the name. for example:

typedef struct Message Message;
int tryEncode(const Message* msg);

=>

struct Message;
int tryEncode(importConstPointer!(Message)* msg);

Unnecessary template

Perhaps it should be marked inout?

March 01
Gravatar of DakotaPosted by Dakota
in reply to ryuukk_		Reply
Dakota
Gravatar of Dakota
Posted in reply to ryuukk_


Reply

On Friday, 1 March 2024 at 11:16:56 UTC, ryuukk_ wrote:

> >

I suggestion add a dmd flags to change the behavior, like --importC-const-pointer=. so the user can choice what kind behavior they want.

some project use transitive const in C, so they can work with this new options.

One more options is translate it into a user-defined template, this is more flexible. user can return diff result base on the name. for example:

typedef struct Message Message;
int tryEncode(const Message* msg);

=>

struct Message;
int tryEncode(importConstPointer!(Message)* msg);

Unnecessary template

Perhaps it should be marked inout?

In some case inout make sense, in other case it should be const and not allow accept non-const. so I think a options for dmd or template will let user do the choice.

March 02
Gravatar of Walter BrightPosted by Walter Bright
in reply to Dakota		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Dakota


Reply
The trouble is that D's semantic code simply does not support non-transitive const, this is worked fundamentally into the type system. Any other method I can think of is going to have seams and warts.
March 02
Gravatar of Jonathan M DavisPosted by Jonathan M Davis
in reply to Walter Bright		Reply
Jonathan M Davis
Gravatar of Jonathan M Davis
Posted in reply to Walter Bright


Reply
On Saturday, March 2, 2024 12:01:40 PM MST Walter Bright via Digitalmars-d wrote:
> The trouble is that D's semantic code simply does not support non-transitive const, this is worked fundamentally into the type system. Any other method I can think of is going to have seams and warts.

Honestly, given C's semanticts for const, I'm tempted to argue that it isn't even correct to treat anything as const when passing it to extern(C) functions. Ultimately, it's an @system thing, because D's type system guarantees aren't in place, but fundamentally, if you pass a const pointer to C from D, you're not getting any actual promises about it - to the point that you're effectively casting it to mutable when passing it.

- Jonathan M Davis
March 04
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to Walter Bright		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to Walter Bright


Reply
On 03/03/2024 8:01 AM, Walter Bright wrote:
> The trouble is that D's semantic code simply does not support non-transitive const, this is worked fundamentally into the type system. Any other method I can think of is going to have seams and warts.

My suspicion is that headconst will be implemented in D at some point, its a question of when not if.

So all this talk about what to do because of us not having it is a tad amusing to me.
March 03
Gravatar of Walter BrightPosted by Walter Bright
in reply to Jonathan M Davis		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Jonathan M Davis


Reply
On 3/2/2024 7:05 PM, Jonathan M Davis wrote:
> Honestly, given C's semanticts for const, I'm tempted to argue that it isn't
> even correct to treat anything as const when passing it to extern(C)
> functions. Ultimately, it's an @system thing, because D's type system
> guarantees aren't in place, but fundamentally, if you pass a const pointer
> to C from D, you're not getting any actual promises about it - to the point
> that you're effectively casting it to mutable when passing it.

Hence my suggestion of:

    #define const

when having difficulties with non-transitive const!
March 04
Gravatar of DakotaPosted by Dakota
in reply to Walter Bright		Reply
Dakota
Gravatar of Dakota
Posted in reply to Walter Bright


Reply

On Monday, 4 March 2024 at 02:22:51 UTC, Walter Bright wrote:

>

Hence my suggestion of:

#define const

when having difficulties with non-transitive const!

Thanks again for all the explain and tips.

from a C library user perspective:

  1. the struct pointer is represents a resource handle
  2. all resource is create and destroy by the library
  3. to access the resource property, use api function
  4. resource has attribute of const, and non-const type. and they are create and pass in and out into function call chain (a lot mix const and non-const)
  5. From the perspective of a library user, a resource pointer is an opaque type.

in your point of view, the const pointer must behavior transitive, not what the c library expected. this make no sense for an opaque type. (you dont have the struct definition some time). You are try interacting with the c library the D ways, not C ways.

So until we get headconst, let user made the choice or force convert into const(type)* will be my choice.

right now I will try some libcang solution, importC not work for me here.

« First   ‹ Prev
1 2
Next ›   Last »