On 24/06/14 11:12 AM, Gregory Maxwell wrote: > On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay <[email protected]> wrote: >> I don't understand why this would be better than either `checked {}` or >> checked operators along with an opt-in lint to catch unchecked >> operators. It's far better than simply saying stuff is unspecified and >> not actually attempting to tackle the problem. If you can't depend on >> the semantics then there's no reason to have the feature. > > Because there are many places where the runtime cost is unacceptable— > as you've pointed out yourself. But running tests and debug builds > with that cost is seldom an unacceptable hit and can improve code > quality a lot, plus static analysis can make use of the additional > information. But all of this is unworkable if the code is full of > harmless overflows because overflow was a perfectly acceptable thing > to do in all cases. > > The behavior of non-checked non-wrapping types could be specified > in-so-far as they _either_ wrap or fault, up to the implementation... > and a checked{} block could force the latter.
A language full of implementation defined behaviour and language dialects via compiler switches has no place in 2014. A top-level `#![checked]` flag with the ability to turn it off in performance critical scopes will work fine if the claims about compiler optimization passes here are true. I don't see a reason to have a compiler switch when most of the people who want this feature are so certain that it can be made cheap. >> Simply making it unspecified makes 0% of the operations checked because > few people will ever pay the huge performance cost to enable them, > > I would expect that virtually everyone would run enable them in > testing/QA builds, and all static analysis tools would make use of the > additional information (e.g. that if it can prove that some series of > operations will cause an overflow, thats a bug). > >> This proposal is just the same stuff that has already been proposed > without any response to most of the issues raised by those on the other > side of the fence > > It seemed pretty clear to me that he was attempting to try to balance > the concerns. Perhaps he failed, but you spent half your message > dismissing his attempted compromises before saying he made none at > all. He wasn't trying to balance the concerns, he was presenting the same proposal yet again and not addressing the concerns that have been raised. There were no attempts at compromising, it's the same thing as the other proposals but presented as if it's a compromise.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
