Postfix type notation - readability and parsing?

[aliak]

This is the most "readable" formatting I could think of for long 
declarations with current syntax.

static immutable Option!(ushort, "p|port", "Sets the port used 
for serving.", "PORT", 8888)
         port;
static immutable Option!(int, "db-port", "Sets the port to use 
for connecting to the db", "DB_PORT", 5432)
         dbPort;
static immutable Option!(string, "db-host", "Sets the port to use 
for connecting to the db", "DB_HOST", "127.0.0.1")
         dbHost;

The template declaration is quite long so:

1) putting the variable name at the end makes it hard to see and 
you'd need to scroll horizontally to get to see what this type is 
for.

2) doing it like the above is confusing to see which name belongs 
to which type because you're so used to a type declaration being 
on one line.

3) Splitting it over multiple lines like:

static immutable Option!(
     ushort,
     "p|port",
     "Sets the port used for serving.",
     "PORT",
     8888
) port;

Turns a potentially X line file in to a X * 10 line file, and you 
have scroll just to see what all the variables are

4) Deciding to go with a mixin approach so you can have the 
variable name on the left and on the same line like:

mixin Option!("port", ushort, "p|port",  "Sets the port used for 
serving.", "PORT",  8888);

destroys any chance of auto completion on the enclosing type, and 
also means you have to implement two types (the mixin template 
and the underlying type - i.e. Option and OptionImpl)

5) putting it on the right after an opAssign ala:

auto port = Option!(...)

means you can't initialize any immutable data in constructors 
since the initialization happens in the declaration line.

If we had postfix then:

static immutable port: Option!(ushort, "p|port", ...);
static immutable dbPort: Option!(int, "db-port",...)
static immutable dbHost: Option!(string, "db-host",...)

Without line wrapping you can see all the main information you 
need with a glance of the code. Isn't that more readable (in this 
scenario)?

The same would apply for functions with long types like this:

SomeType!("this is the first", int, "some other thing goes here" 
foo() {
}

vs

function foo(): SomeType!("this is the first", int, "some other 
thing goes here") {
}

You can't find out that it's a function until you move your eyes 
all the way to the right in the former, but the latter is 
instantaneously apparent.

Consistency could also increase because you will have this:

auto a: int;
const b = 3;

instead of:

int a;
const b = 3;

The type is an inferred type or an explicit type but they can 
bother be on the right?

And finally, I'm curious how this would effect parsing? Maybe 
someone familiar with dmd internals can say if things would be 
easier? Because it feels like currently you need to look ahead 
when you see "int identifier" - is it a variable or function? 
Can't know until you go farther right? Are there other situations 
like this?

Cheers,
- Ali