--- Comment #4 from Andrei Alexandrescu <and...@metalanguage.com> 2009-10-30
08:51:31 PDT ---
(In reply to comment #3)
> > -safe: "Do whatever the hell it takes to make sure my program never has a
> > memory error"
> > -release: "I've tested and debugged my programs, eliminate runtime design
> > checks"
> > Compiling with -safe implies array bounds checks stay, come hell or high
> > water.
> > Compiling with -release means the contracts and assert are removed. Those
> > can't
> > cause memory errors. Only non-safe builds will remove array bounds checks.
> The current -safe guarantees that you never have to debug memory corruption
> problems, which can be notoriously difficult to track down.
Yes. Well, that's the intent - the feature is not finished.
> I would use it 100%
> of the time. But I'd always have bounds checking off in production code, it
> hurts performance too much.
What you want is impossible as far as we know. Safety and no bounds checking
cannot be done with the current technology, or at least not in a way that's not
onerous (e.g. a 12-hour analysis of a 10,000 lines program).
> Actually, I think what this issue is, is that you need an option to have
> contracts and asserts turned off, while leaving bounds checking on.
> compile runtime
> safe bounds contracts
> Y Y Y
> Y N N <---- I want to keep this option
> Y Y N <---- You're saying we need this option
> I think -release is a misnomer, and should be split in two.
I agree. You may want to make a proposal, and quick. At any rate, today "-safe"
is the best-defined notion we have and I think it would be difficult to
convince people that -safe and no bounds checking make sense together.
BTW, there's nothing special about compile-time vs. run-time in "safe". Memory
safety asks for a combo solution. Oftentimes a runtime check could be hoisted
to compilation time.
> (Actually I think since we have module(system), we'll probably be able make
> -safe mandatory, eventually).
That would be great!
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------