== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> dsimcha wrote:
> > Ok, I understand the basic principle of a reap, but if it's going to convert to a heap when you try to delete something, why not just improve the standard GC heap, i.e. by making per-thread heaps?
> The problem with per-thread heaps is immutable data can be passed between threads.

What does this have to do with anything?  If allocation is done w/o locking by using TLS, (manual) freeing could simply check that the thread ID of the block matches the thread ID of the thread doing the freeing and if so, free the memory to the thread-local heap w/o locking.  Of course, GCing would still have to stop the world.

Adam D. Ruppe wrote:
> With safe by default, you'd probably make existing code compile just by
> slapping @trusted: at the top and being done with it. That's not actually
> safe - you're just telling the compiler to shut up about it.

That's right, and it's exactly what happened when Java required exception specifications for all thrown exceptions. It's viral, and people would just write wrappers to catch/ignore all exceptions, intending to "fix it" later.

But the fixing later never came, and the app would silently ignore all errors.

Walter Bright Wrote:

> Andrei Alexandrescu wrote:
> > Nick Sabalausky wrote:
> >> Sounds great! The lower-grained safeness makes a lot of sense, and I'm thrilled at the idea of safe D finally encompassing more than just memory safety - I'd been hoping to see that happen ever since I first heard that "safeD" only ment memory-safe.
> > 
> > I can think of division by zero as an example. What others are out there?
> 
> Casting away const/immutable/shared.

I posted in the other thread how casting to immutable/shared can be just as bad. A leaked reference prior to casting to immutable/shared is in effect the same as casting away shared. No matter how you mix thread local and shared, or mutable and immutable, you still have the same undefined behavior

On 2009-11-05 16:40:11 -0500, "Adam D. Ruppe" <destructionator@gmail.com> said:

> Which is going to work best for existing code? With Walter's idea, you
> compile it, then fix functions piece by piece to make them safe. Since your
> other unsafe functions can still call them, the change is localized and you
> get safer with each revision.
> 
> With safe by default, you'd probably make existing code compile just by
> slapping @trusted: at the top and being done with it. That's not actually
> safe - you're just telling the compiler to shut up about it.

That's a great point. Thank you Adam. I changed my mind, let's keep unsafe as the default.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Nick Sabalausky wrote:
>>> Sounds great! The lower-grained safeness makes a lot of sense, and I'm thrilled at the idea of safe D finally encompassing more than just memory safety - I'd been hoping to see that happen ever since I first heard that "safeD" only ment memory-safe. 
>>
>> I can think of division by zero as an example. What others are out there?
> 
> Casting away const/immutable/shared.

I think those lead to memory errors :o).

Andrei

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> Well I'm thinking that often when you use a region, the memory
>> consumption is not really large. If it's really large, then you may be
>> better off just using the GC because it means you do a lot of stuff. But
>> I'm sure I'm ignoring a few important applications.
>> Andrei
> 
> By not really large, how big are we talking?  Less than a few 10s of KB?  If so, I
> think just having the whole thing scanned would be feasible.

Honest, I don't know. Only real-life usage might tell. At any rate, a few 10s of KBs would definitely work for many of my own applications.

Andrei

Jason House wrote:
> I posted in the other thread how casting to immutable/shared can be
> just as bad. A leaked reference prior to casting to immutable/shared
> is in effect the same as casting away shared. No matter how you mix
> thread local and shared, or mutable and immutable, you still have the
> same undefined behavior

Not undefined, it's just that the compiler can't prove it's defined behavior. Hence, such code would go into a trusted function.

On 2009-11-05 17:11:38 -0500, Walter Bright <newshound1@digitalmars.com> said:

> dsimcha wrote:
>> Ok, I understand the basic principle of a reap, but if it's going to convert to a
>> heap when you try to delete something, why not just improve the standard GC heap,
>> i.e. by making per-thread heaps?
> 
> The problem with per-thread heaps is immutable data can be passed between threads.

Well, if that's a problem you could fix it by making immutable not shared unless you also put the shared attribute:

	immutable Object o;        // thread-local
	shared immutable Object o; // visible from all threads

I think having per-thread heaps is a worthy goal.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Thu, 05 Nov 2009 17:49:33 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> Jason House wrote:
>> I posted in the other thread how casting to immutable/shared can be
>> just as bad. A leaked reference prior to casting to immutable/shared
>> is in effect the same as casting away shared. No matter how you mix
>> thread local and shared, or mutable and immutable, you still have the
>> same undefined behavior
>
> Not undefined, it's just that the compiler can't prove it's defined behavior. Hence, such code would go into a trusted function.

But how does such a trusted function guarantee that the invariant/shared reference has no other aliases?  The point is, there is no way to write such a function in good faith because you can't guarantee it's actually safe, it's still up to the user of the function.  My understanding is that a @trusted function should be provably safe even if the compiler can't prove it.

-Steve

Walter Bright wrote:
> Jason House wrote:
>> I posted in the other thread how casting to immutable/shared can be
>> just as bad. A leaked reference prior to casting to immutable/shared
>> is in effect the same as casting away shared. No matter how you mix
>> thread local and shared, or mutable and immutable, you still have the
>> same undefined behavior
> 
> Not undefined, it's just that the compiler can't prove it's defined behavior. Hence, such code would go into a trusted function.

Are we in agreement that @safe functions have bounds checking on regardless of -release?

Andrei