November 30, 2017
On Thursday, 30 November 2017 at 03:29:56 UTC, Walter Bright wrote:
> The code *size* causes problems because it pushes the executing code out of the cache.

Not if you do a branch to a cold cacheline on assert failure.

November 30, 2017
On 30.11.2017 04:29, Walter Bright wrote:
> 
> The code *size* causes problems because it pushes the executing code out of the cache. Another issue (I should check this again) was doing null checks on member function calls, which is not necessary since if they're null it'll seg fault.

This is not true for final member functions.
November 30, 2017
On Thursday, November 30, 2017 09:37:30 Timon Gehr via Digitalmars-d wrote:
> On 30.11.2017 04:29, Walter Bright wrote:
> > The code *size* causes problems because it pushes the executing code out of the cache. Another issue (I should check this again) was doing null checks on member function calls, which is not necessary since if they're null it'll seg fault.
>
> This is not true for final member functions.

It's close enough. Instead of segfaulting when the member function is called, it'll segfault when it tries to access one of the member variables or non-final member functions inside the member function. So, there isn't any more need to add null checks for final member functions than there is for non-final member functions.

- Jonathan M Davis

November 30, 2017
On Thursday, 30 November 2017 at 09:01:20 UTC, Jonathan M Davis wrote:
> function is called, it'll segfault when it tries to access one of the member variables

Is there an upper limit for how large an object can be?

November 30, 2017
On Thursday, November 30, 2017 09:56:35 Ola Fosheim Grøstad via Digitalmars- d wrote:
> On Thursday, 30 November 2017 at 09:01:20 UTC, Jonathan M Davis
>
> wrote:
> > function is called, it'll segfault when it tries to access one of the member variables
>
> Is there an upper limit for how large an object can be?

Not AFAIK, but it _is_ my understanding that if a type is large enough (larger than the page size IIRC), a segfault won't be triggered when the reference or pointer is null, and in those cases, we really do need to add null checks in @safe code, or the code isn't going to truly be @safe. That's completely separate from whether a function is final or not though, and it would apply to pointers to structs as well as class references.

- Jonathan M Davis


November 30, 2017
On Thursday, 30 November 2017 at 10:14:26 UTC, Jonathan M Davis wrote:
> the code isn't going to truly be @safe. That's completely separate from whether a function is final or not though, and it would apply to pointers to structs as well as class references.

Indeed. So maybe the compiler find the get the largest object for a given program and protect the same amount of pages?

I guess pointers to C-style arrays would still be an issue, but probably not as frequently used in D.

November 30, 2017
On Thursday, 30 November 2017 at 10:23:09 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 November 2017 at 10:14:26 UTC, Jonathan M Davis wrote:
>> the code isn't going to truly be @safe. That's completely separate from whether a function is final or not though, and it would apply to pointers to structs as well as class references.
>
> Indeed. So maybe the compiler find the get the largest object

"can find and get the size of the largest object…"

(not sure what happend there :)

November 30, 2017
On Thursday, 30 November 2017 at 09:01:20 UTC, Jonathan M Davis wrote:
> It's close enough. Instead of segfaulting when the member function is called, it'll segfault when it tries to access one of the member variables or non-final member functions inside the member function. So, there isn't any more need to add null checks for final member functions than there is for non-final member functions.

Err... wait. What if you have a conditional:

    if(input == 0) { do something bad }
    access field

Seems like you would be better off by injecting:

   assert this not null

at the beginning of all final methods and remove the assertion if all paths will lead to a field access before something bad can happen.

Adding checks and then only remove them if they provably have no consequence tend to be the safer approach.

November 30, 2017
On Thursday, 30 November 2017 at 10:39:07 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 November 2017 at 09:01:20 UTC, Jonathan M Davis wrote:
>> It's close enough. Instead of segfaulting when the member function is called, it'll segfault when it tries to access one of the member variables or non-final member functions inside the member function. So, there isn't any more need to add null checks for final member functions than there is for non-final member functions.
>
> Err... wait. What if you have a conditional:
>
>     if(input == 0) { do something bad }
>     access field

Or even worse:

if (input != 0) access fields
else do bad stuff


November 30, 2017
On 2017-11-30 04:23, Walter Bright wrote:

> At this point, relying on druntime not changing is just not realistic. libc is different, having been cast in stone for nearly 30 years now.

There are still problems with libc on Linux. One cannot assume a binary compiled one distribution works on another. So currently I think it's create that all D code is statically linked.

-- 
/Jacob Carlborg