On Thursday, 15 November 2012 at 22:04:27 UTC, David Nadlinger
wrote:
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote:
I disagree, you can always fallback to using user defined
types... but it _allows_ for native types also, i.e. more
flexible.
You are missing the point: In your proposal, if you want to use
two libraries together which are expecting you to provide e.g.
'int' annotations, you are screwed. This is a big, BIG problem.
David
no, I implied the solution already... actually there are many
different ways to solve it... some possible today, some require
new minor support features(like sending the annotated symbol as a
template alias parameter to the annotation)... but could give us
compile time errors when ambiguity is detected.
In the common case there are no collisions, so most of the time
we can use the nice user-friendly syntax!
[lib1.x]
struct User
{
[1] int uid;
}
But we _can_ disambiguate when needed...
[lib1.x, lib2.y]
struct User
{
[lib!1, lib2!2] int uid; // ok
[1, lib2!2] int uid; // ok
[lib1!1, 2] int uid; // ok
[1,2] int uid; // not supported
[1] int uid; // not supported
}
lib2 doesn't have to know about lib1.
lib1 doesn't have to know about lib2.
Because they just have to check the annotation in _prioritized_
order.
1. find my unique lib2.y symbol
2. if there is a lib2!uint on a nested symbol, use it...
3. if not check for a native int.
