Comment # 17 on bug 126 from Mike

I hope we can all agree that volatile semantics are necessary for this kind of
programming regardless of whether it is implemented as an asm workaround,
compiler intrinsic functions, or a type qualifier.

I also hope we can all agree that neither shared nor shared+atomic, when
properly implemented, provides volatile semantics (See Iain's last comment
[http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c10] and DIP 4.2.4 -
[http://wiki.dlang.org/DIP62#Why_volatile_and_shared_can.27t_be_merged]). 
Please correct me if I'm wrong. 

I think DIP62 4.2.2 justifies why it should be a type qualifier
[http://wiki.dlang.org/DIP62#Why_a_type_qualifier]:  because one would never
want to access a volatile memory location without volatile semantics.  Using a
type qualifier would give the programmer this guarantee but volatile get/set
(i.e. peek/poke) intrinsic functions would not.

I have yet to hear an equally strong argument in favor of get/set intrinsics.  
Until such time, I support DIP62.