On 7/30/14, 9:31 AM, Timon Gehr wrote:
On 07/30/2014 05:04 PM, Andrei Alexandrescu wrote:
On 7/30/14, 4:56 AM, Daniel Murphy wrote:
"Artur Skawina via Digitalmars-d" wrote in message
news:mailman.217.1406713015.16021.digitalmar...@puremagic.com...
`assert` is for *verifying* assumptions. It must not allow them
to leak/escape. Otherwise a single not-100%-correct assert could
defeat critical runtime checks.
All you're saying is you want them to have different names, not that it
can't work the way Walter and I have described. If your assertions are
invalid and you're compiling with -release, the compiler is free to
generate invalid code. -release is dangerous. -release is telling the
compiler that the code you wrote is correct, and it can rely on it to
be correct.
Exactly! -- Andrei
This just moves the issue around and gives another term a non-obvious
meaning (the 'release' switch, which is not called e.g.
'unsafeAssumeCorrect'.
Well to me "-release" is "I assume my program is correct, generate the
fastest code for it".
Which is still confusing, because it purports to
keep memory safety intact in @safe code by not disabling array bounds
checks by default). This is the very topic of this discussion: some
people get confused when they are assumed to use standard terms with
non-standard meanings. I was objecting to the apparent attitude that
this is entirely the fault of the one who gets confused, or that it is
symptomatic for lack of understanding of concepts.
I'm not sure what would be the standard misused term in this case.
I mean, we have at least:
some terms with whacky meanings for an outsider:
'release' which does not relate to a released code version and which is
not in contrast to 'debug'.
Yeah, it's a sensible point. I don't like that either, but it's a minor
annoyance at most.
'const' which does not relate to being a constant.
"Like C++ const, but transitive".
'enum' which does not denote enumeration in many contexts where it is used.
Sensible point, but in our use at Facebook I noticed engineers picking
it up without a hitch.
'in' which does not only check for membership but rather returns a
pointer to that member.
It's conveniently terse.
'lazy', which denotes pass by name instead of pass by need.
It's not pass by name.
'pure' which denies access to mutable static variables and IO.
That's the consequence of functional purity as defined by D. I see
nothing wrong with it.
... (some more easily debatable ones removed)
some terms with inconsistent meanings:
'alias': alias declarations and alias parameters are notably distinct:
while I can alias a built-in type to a symbol, I cannot pass it by
alias. The following fails:
template T(alias a){ enum T=2; }
pragma(msg, T!string);
Agreed.
(Before debate ensues: I am completely aware of what each of the above
actually mean and do.)
I think you got a point there but if you searched any programming
language in its pockets you're liable to find a bunch of similar lint.
It's the way it goes - there's a need to maximize expressiveness while
keeping vocabulary and grammatical constructs low. Few of these items
are near the top of my list of issues in D, and I think the same goes
for your list.
To me, the apt response to a relative newcomer who gets confused by one
of those or something like them, especially when used without quotation
marks, is not at all similar to "You're misunderstanding and misusing
this feature, stop making noise."
Consider this: after considerable effort you are failing to explain your
case for "assume" to the language creators. How do you think you'll fare
with newcomers?
Andrei
