The obligatory permalink and latest draft.

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

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

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.

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

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.

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

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?

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

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.

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

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.

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?

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.