Thread overview
Fourth Draft: Primary Type Syntax
Sep 26
Tim
Oct 04
Dukc
Oct 07
Dukc
Oct 19
Dukc
September 24

The obligatory permalink and latest draft.

The only difference is new subsections of § Maximal Munch Exceptions.

September 26

On Tuesday, 24 September 2024 at 20:50:58 UTC, Quirin Schroll wrote:

>

The obligatory permalink and latest draft.

The only difference is new subsections of § Maximal Munch Exceptions.

The new sections look good.

Currently the spec only mentions maximal munch for the lexer and not the parser.

The typo excpetion is now twice in the document.

September 26

On Thursday, 26 September 2024 at 18:05:51 UTC, Tim wrote:

>

On Tuesday, 24 September 2024 at 20:50:58 UTC, Quirin Schroll wrote:

>

The obligatory permalink and latest draft.

The only difference is new subsections of § Maximal Munch Exceptions.

The new sections look good.

Currently the spec only mentions maximal munch for the lexer and not the parser.

The typo excpetion is now twice in the document.

I just don’t understand how we live in 2024 and Visual Studio has no working spellcheck on Markdown.

The proper spelling and some other wording issues are resolved now.

October 04

On Tuesday, 24 September 2024 at 20:50:58 UTC, Quirin Schroll wrote:

>

The obligatory permalink and latest draft.

The only difference is new subsections of § Maximal Munch Exceptions.

A question, probably out of ignorance: Why do function pointers / delegates need to care about their linkage type?

I thought that a function pointer can freely point to any function that is otherwise of the correct type, regardless of it's linkage type. Is this not the case?

October 05
On 05/10/2024 12:13 AM, Dukc wrote:
> On Tuesday, 24 September 2024 at 20:50:58 UTC, Quirin Schroll wrote:
>> The obligatory [permalink](https://github.com/Bolpat/DIPs/blob/fcb076e4be19abf634bcadbb7567c49ed80c084c/DIPs/DIP-2NNN-QFS.md) and [latest draft](https://github.com/Bolpat/DIPs/blob/PrimaryTypeSyntax/DIPs/DIP-2NNN-QFS.md).
>>
>> The only difference is new subsections of [§ Maximal Munch Exceptions](https://github.com/Bolpat/DIPs/blob/fcb076e4be19abf634bcadbb7567c49ed80c084c/DIPs/DIP-2NNN-QFS.md#maximal-munch-exceptions).
> 
> A question, probably out of ignorance: Why do function pointers / delegates need to care about their linkage type?
> 
> I thought that a function pointer can freely point to any function that is otherwise of the correct type, regardless of it's linkage type. Is this not the case?

No.

Linkage affects both mangling and the ABI (how it is called).

Parameters and return values could be in different locations if it was mixed up.

October 07

On Friday, 4 October 2024 at 22:24:15 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

No.

Linkage affects both mangling and the ABI (how it is called).

Parameters and return values could be in different locations if it was mixed up.

I see, thanks. In that case it's good that the DIP addresses it.

In general I like a lot about this DIP is proposing but I should do a deeper dive. Maybe I will but not today.

October 19

Time for another dive. I still generally like this proposal. But I did gather
a few issues.

>

However, unless misleading spaces are inserted between the type qualifier and the opening parenthesis, this exception follows mathematical conventions and programmers’ intuition

This left me confused for quite a while. The exception to parsing rules that
the present language has, or exception relative to current meaning the suggested
changes could lead to?

I did figure out you meant that the meaning of const(int)[] will NOT change,
but it took me some time to insure myself of that.

>

linkage

In declarations, linkage works mostly like attributes (both user-defined and
language-defined) do. Would it be better for them to be declared like
attributes are for function pointers and delegates: after the parameter list?
In other words, extern qualifiers would become part of FunctionAttribute in
the grammar. Of course, this should be allowed for all function declarations,
not just function pointers/delegates.

There's one potential weakness in my idea though: it assumes that non-function
pointers don't and won't care about the linkage of the pointee. Should we
assume this is the case? I don't know.

Regardless, probably ref is best left at the beginning like proposed though.
Were ref allowed at end of the attribute list, the meaning of scope ref or
return ref in a member function would be really confusing: does it make the
this reference (that the scope/return applies to) ref or the return
type?

>

anonymous classes

Example? I maybe know what you're writing about and proposing here but it's hard to be sure.


Maybe while there, you could also propose a syntax for function types without
needing alias declarations for that? It doesn't have to be particulary pretty
since we're usually not supposed to use them, but I still think they should be
grammatically valid.