@safe leak fix?

grauzone none at example.net
Wed Nov 11 14:21:44 PST 2009


Walter Bright wrote:
> grauzone wrote:
>> Walter Bright wrote:
>>> The code will be a little slower, but it will be memory safe. This 
>>> change wouldn't be done in trusted or unsafe functions.
>> That's just idiotic. One of the main uses of static arrays is to 
>> _avoid_ heap memory allocation in the first place. Do what you want 
>> within @safe,  but leave "unsafe" (oh god what a pejorative) alone.
> 
> Well, I did propose only doing this in safe functions!

In this case, the semantic difference between safe and unsafe functions 
will cause trouble, and you'd eventually end up imposing the "safe" 
semantics upon unsafe functions.

I'd vote for disallowing slicing in safe functions. Safe code can just 
use dynamic arrays instead. One other important use of arrays will be 
small SSE optimized vectors (as far as I understood that), but those 
should be fine in safe mode; usually you won't want to slice them.

> Also, I agree with "unsafe" being a pejorative. Got any better ideas? 
> "unchecked"?

Some brainstorming: highperf, fast mode, system mode, lowlevel, 
bare-metal, turbo mode (silly but fun), ...?



More information about the Digitalmars-d mailing list