Thread overview
Second Draft: Primary Type Syntax
Jul 25
IchorDev
Jul 25
IchorDev
Jul 26
IchorDev
May 29

https://github.com/Bolpat/DIPs/blob/0bfe22921d99ea18f9a669e13e4c00741c82a63a/DIPs/DIP-2NNN-QFS.md

Major changes

  • Added proposing to fix Issue 24007, too.
  • Simplified the grammar changes
  • Better table of contents
  • Added a section exploring an alternative that preserves the max munch principle
  • Added a section dedicated to linkage attributes

Abstract

The goal of this proposal is that every type expressible by D’s type system also has a representation as a sequence of D tokens.
The type constructs that lack a representation are function pointer and delegate types that return by reference and/or have a non-default linkage.

July 25

On Wednesday, 29 May 2024 at 18:22:03 UTC, Quirin Schroll wrote:

>

Abstract

The goal of this proposal is that every type expressible by D’s type system also has a representation as a sequence of D tokens.
The type constructs that lack a representation are function pointer and delegate types that return by reference and/or have a non-default linkage.

The fact that this currently isn’t possible feels like a stupid oversight. Especially important to me is being able to use extern(C) without having to make an alias. And the proposed grammar looks great.

July 25

On Thursday, 25 July 2024 at 09:15:56 UTC, IchorDev wrote:

>

On Wednesday, 29 May 2024 at 18:22:03 UTC, Quirin Schroll wrote:

>

Abstract

The goal of this proposal is that every type expressible by D’s type system also has a representation as a sequence of D tokens.
The type constructs that lack a representation are function pointer and delegate types that return by reference and/or have a non-default linkage.

The fact that this currently isn’t possible feels like a stupid oversight. Especially important to me is being able to use extern(C) without having to make an alias. And the proposed grammar looks great.

Thank you. If extern(C) is important to you, I’d really, really appreciate help in making it work. Currently, I’m focusing on ref to be honest, in particular integrating the ref variable support merged yesterday. Some Notes in the DIP outright say: My implementation can parse linkages (for the most part), but it does not apply them to the function/delegate type. It’s not like my parse.d code just skips linkages. It does assign the seen linkage to the function type, but somewhere further down, that linkage is ignored or gets lost.

July 25

On Thursday, 25 July 2024 at 13:36:23 UTC, Quirin Schroll wrote:

>

Thank you. If extern(C) is important to you, I’d really, really appreciate help in making it work. Currently, I’m focusing on ref to be honest, in particular integrating the ref variable support merged yesterday. Some Notes in the DIP outright say: My implementation can parse linkages (for the most part), but it does not apply them to the function/delegate type. It’s not like my parse.d code just skips linkages. It does assign the seen linkage to the function type, but somewhere further down, that linkage is ignored or gets lost.

I must say, working on dmd is not my strong suit, but in a few weeks I might have some spare time to at least attempt to help. I’d also like to know whether either of the language maintainers look like they are on board with this idea before dedicating too much time to an implementation. (Maybe one of us can mention it to Walter at this month’s meeting?)

July 25

On Thursday, 25 July 2024 at 15:15:27 UTC, IchorDev wrote:

>

On Thursday, 25 July 2024 at 13:36:23 UTC, Quirin Schroll wrote:

>

Thank you. If extern(C) is important to you, I’d really, really appreciate help in making it work. Currently, I’m focusing on ref to be honest, in particular integrating the ref variable support merged yesterday. Some Notes in the DIP outright say: My implementation can parse linkages (for the most part), but it does not apply them to the function/delegate type. It’s not like my parse.d code just skips linkages. It does assign the seen linkage to the function type, but somewhere further down, that linkage is ignored or gets lost.

I must say, working on dmd is not my strong suit, but in a few weeks I might have some spare time to at least attempt to help

Neither it’s mine. This is my first real attempt to do something with the compiler.

I just finished integrating Walter’s PR that enabled ref variables. When I started the implementation, ref variables were a pipe dream, so at various places, there were assumptions that X or Y isn’t possible, but now it is.

I see the implementation more as a proof of concept. It very likely has issues all over the place, but the deal is, an implementation (even a sketchy one, I hope) makes it more likely to get a DIP accepted. And if people can experiment with it, it’s probably a win, too.

(I mean, Walter’s ref variable implementation isn’t perfect either.)

>

I’d also like to know whether either of the language maintainers look like they are on board with this idea before dedicating too much time to an implementation.

I’m throwing this idea around for a while now. As of now, it hasn’t faced much opposition. After all, it’s a problem that to my knowledge everyone agrees needs fixing and, while the proposal has become lengthy, it’s actually a quite innocuous change.

>

(Maybe one of us can mention it to Walter at this month’s meeting?)

Anyone can join the monthly meeting? I didn’t know that. If I misunderstood you, but you’re invited, yes, please bring this to higher-ups’ attention. IMO, it’s embarrassing that D can’t express various types directly.

July 26

On Thursday, 25 July 2024 at 20:38:42 UTC, Quirin Schroll wrote:

>

Anyone can join the monthly meeting? I didn’t know that.

As far as I know yes. You can ask Mike Parker & let him know you want to discuss your DIP idea.