DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Walter Bright via Digitalmars-d]

On 7/15/2014 6:03 PM, Mike wrote:
> OT:  Isn't inp/outp and Intel-only thing, though?

Of course. But it's still used on embedded systems.


> DIP62 addressed why peek/poke are not the right tool for the job in the "why a
> type qualifier" section.  In summary, one would never want to access volatile
> memory with non-volatile semantics, and a type qualifier is the only proposal
> I've seen that enforces that:  peek/poke intrinsics do not.

See my reply to Steve Sobel.


>  From what I've read in this thread, I suspect you favor peek/poke due to the
> complexity it introduces into the implementation. If a 'volatile' type qualifier
> was a trivial implementation, and did not introduce complexity into
> implementation, would your position be different?

Unfortunately, it isn't trivial, so your point is moot. Even if it were, 
"trivial" is not a good reason to put a feature in a language. The language must 
not become a kitchen sink grab-bag of trivia. Go has demonstrated there is 
considerable value in having a small set of orthogonal features instead.


> I remember watching a talk you gave where you compared code with an airplane,
> and how when you get it right, it just looks like it wants to fly.  I don't know
> how many people got that, but I sure did.

You're the only one that likes my airplane metaphors :-)


> A type qualifier is an elegant tool for modeling one's hardware because at every
> usage, it already knows how, and wants to fly.

Type qualifiers are not elegant. Type qualifiers are fairly burdensome to the user.