I'm not sure how AST macros would assist in thread safety the way
that this feature would. Maybe you could elaborate?
To explain a little more, when you put a @thread:name or
@sync(object) attribute on something, the compiler will guarantee
that no safe D code will ever use that code or data unless it is
either on the given thread or can guarantee at compile time that
it has synchronized on the given object.
You mentioned making the variable thread local. So if I'm
understanding, you're saying just make it a regular global
variable. However, the point is that if you tell the compiler
that it can only be accessed by a single thread then it doesn't
need to be thread local. Real global variables are preferred
over thread local for performance/memory reasons. Their address
is known at compile time and you don't need to allocate a new
instance for every thread. The only reason for thread local
variables is to alleviate problems with multithreaded
applications, but using an attribute like this would allow
someone to have the benefit of a real global variable without
exposing it to other threads fixing the synchronization issue.
D has its own way of handling multithreaded applications but I
still have applications that use the old idioms to get lightning
performance and minimize memory usage. A feature like this could
solve alot of problems the old idioms use. There are many times
that I write a function and I have to make a mental note (or a
comment) that this function should only ever be called by a
certain thread. Or that this function should only be called by
code that has locked on a certain object. It would be wonderful
if the compiler could guarantee that for me.
