<html>
<head>
<base href="http://bugzilla.gdcproject.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c17">Comment # 17</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126">bug 126</a>
from <span class="vcard"><a class="email" href="mailto:slavo5150@yahoo.com" title="Mike <slavo5150@yahoo.com>"> <span class="fn">Mike</span></a>
</span></b>
<pre>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
[<a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="show_bug.cgi?id=126#c10">http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c10</a>] and DIP 4.2.4 -
[<a href="http://wiki.dlang.org/DIP62#Why_volatile_and_shared_can.27t_be_merged">http://wiki.dlang.org/DIP62#Why_volatile_and_shared_can.27t_be_merged</a>]).
Please correct me if I'm wrong.
I think DIP62 4.2.2 justifies why it should be a type qualifier
[<a href="http://wiki.dlang.org/DIP62#Why_a_type_qualifier">http://wiki.dlang.org/DIP62#Why_a_type_qualifier</a>]: 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>