Fourth Draft: Primary Type Syntax

[Dukc]

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.