http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #17 from Mike <slavo5...@yahoo.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
