"Vast experience has shown us that it is unrealistic to expect programmers to write secure code in memory-unsafe languages."

  https://techcrunch.com/2016/10/01/learned-helplessness-and-the-languages-of-dao/

Memory safe programming languages will become a pervasive design requirement, likely rather soon. D must support memory safe programming or it has no future.

  https://github.com/dlang/dmd/pull/5972

is a major step forward for that.

While on the subject, taking the address of a struct's method returns an incorrect type that allows it to be called incorrectly even with @safe. Which is a bit ironic cause then it can't be cast'd to a type that is actually safe to use.

    auto func = &SomeStruct.someFunc;
    func(); // ops runtime error, allows calling function that needs an object

C++ makes this a pointer to a member function which looks like: "void (SomeStruct::*)()" for the example above. Either way for safety and just having a defined way to call a pointer to a member function would be nice.

On 10/2/2016 4:57 PM, Jacob wrote:
> While on the subject, taking the address of a struct's method returns an
> incorrect type that allows it to be called incorrectly even with @safe. Which is
> a bit ironic cause then it can't be cast'd to a type that is actually safe to use.
>
>     auto func = &SomeStruct.someFunc;
>     func(); // ops runtime error, allows calling function that needs an object
>

Please file bugzilla issues for these sorts of things. Thanks!

> C++ makes this a pointer to a member function which looks like: "void
> (SomeStruct::*)()" for the example above. Either way for safety and just having
> a defined way to call a pointer to a member function would be nice.

http://digitalmars.com/articles/b68.html

On Monday, 3 October 2016 at 01:24:45 UTC, Walter Bright wrote:
> On 10/2/2016 4:57 PM, Jacob wrote:
>> While on the subject, taking the address of a struct's method returns an
>> incorrect type that allows it to be called incorrectly even with @safe. Which is
>> a bit ironic cause then it can't be cast'd to a type that is actually safe to use.
>>
>>     auto func = &SomeStruct.someFunc;
>>     func(); // ops runtime error, allows calling function that needs an object
>>
>
> Please file bugzilla issues for these sorts of things. Thanks!
>
> > C++ makes this a pointer to a member function which looks
> like: "void
> > (SomeStruct::*)()" for the example above. Either way for
> safety and just having
> > a defined way to call a pointer to a member function would be
> nice.
>
> http://digitalmars.com/articles/b68.html

Has existed since 2010... https://issues.dlang.org/show_bug.cgi?id=3720

Also using a proxy is suboptimal, if you use a cast() and add in "ref SomeStruct" as a parameter, it functions properly and doesn't require the proxy.

On 10/2/2016 7:14 PM, Jacob wrote:
> Has existed since 2010... https://issues.dlang.org/show_bug.cgi?id=3720

Thanks. I added the 'safe' keyword.


> Also using a proxy is suboptimal, if you use a cast() and add in "ref
> SomeStruct" as a parameter, it functions properly and doesn't require the proxy.

Could you present a code sample, please?

    import std.stdio;

    struct SomeStruct
    {
        int value;

        void func()
        {
            writeln(value);
        }

    }

    void main()
    {
        SomeStruct someStruct;
        someStruct.value = 333;

        auto func = cast(void function(ref SomeStruct))&SomeStruct.func;

        func(someStruct);
    }

Has worked so far for me.

On Monday, 3 October 2016 at 03:50:29 UTC, Jacob wrote:
>     import std.stdio;
>
>     struct SomeStruct
>     {
>         int value;
>
>         void func()
>         {
>             writeln(value);
>         }
>
>     }
>
>     void main()
>     {
>         SomeStruct someStruct;
>         someStruct.value = 333;
>
>         auto func = cast(void function(ref SomeStruct))&SomeStruct.func;
>
>         func(someStruct);
>     }
>
> Has worked so far for me.

But it can be useful to take the address of the code and to patch the "this" pointer of a delegate later. Used several times.

What's the plan ? to disable this ! Plz no.

On 3 October 2016 at 13:50, Jacob via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>     import std.stdio;
>
>     struct SomeStruct
>     {
>         int value;
>
>         void func()
>         {
>             writeln(value);
>         }
>
>     }
>
>     void main()
>     {
>         SomeStruct someStruct;
>         someStruct.value = 333;
>
>         auto func = cast(void function(ref SomeStruct))&SomeStruct.func;
>
>         func(someStruct);
>     }
>
> Has worked so far for me.

Some ABI's work. D would have to define that all methods use cdecl and eject 'thiscall' into space, which would be cool.

On 10/2/2016 8:50 PM, Jacob wrote:
>     import std.stdio;
>
>     struct SomeStruct
>     {
>         int value;
>
>         void func()
>         {
>             writeln(value);
>         }
>
>     }
>
>     void main()
>     {
>         SomeStruct someStruct;
>         someStruct.value = 333;
>
>         auto func = cast(void function(ref SomeStruct))&SomeStruct.func;
>
>         func(someStruct);
>     }
>
> Has worked so far for me.

That's cool, but it does rely on the ABI of regular functions matching that of member functions, which isn't true on all platforms.