Am Wed, 16 Jul 2014 03:33:35 +1000 schrieb "Daniel Murphy" <yebbliesnos...@gmail.com>:
> "Johannes Pfau" wrote in message news:lq3nf4$rbp$1...@digitalmars.com... > > > Did you even read the section that explains why volatility is a > > property of the memory address and not of the access (4.2.3)? > > What's your response to that? > > This is true, and it's the ideal I guess, but I'm not sure that it > makes it worth extending the type system for. > > My use of volatile in C consists entirely of > > #define SOME_REGISTER (*(volatile unsigned *)(BASE + OFFSET)) > > And this could easily be done in D with a wrapper around peek/poke > functions. (assuming they're intrinsics and inlining/optimization > works correctly) > > So, the complexity it adds to the type system and overloading etc is > not worth it for my use cases. What are the other use cases where it > pulls its weight? > That's a judgement call of course and the main reason why I constantly say 'first class support'. This is the only language change we need for embedded systems, do we really want to compromise here? Especially if C has already got a better solution? There's some complexity in the compiler implementation, indeed. There's also some complexity in the compiler for -cov, for @nogc and for shared. And we recently added complexity to support C++ namespaces. All of these things are completely useless on embedded systems. So I think we could add one slightly complex thing for embedded development. Also there's effectively no increase in language complexity for users, as nobody will use volatile with desktop applications. Volatile is already a reserved & deprecated keyword. We don't break any code. Code on embedded systems will usually be less complex with volatile and it'll be safer. For some examples where this matters: - Memory used in interrupt handlers with redirection - registers with the same layout/type could be referred by pointer