The C99 Standard says:

  #include <string.h>
  void *memcpy(void * restrict s1, const void * restrict s2, size_t n);

  Description

  The memcpy function copies n characters from the object pointed to by s2
  into the object pointed to by s1. If copying takes place between objects
  that overlap, the behavior is undefined.

  Returns

  The memcpy function returns the value of s1.


Rust says https://doc.rust-lang.org/1.14.0/libc/fn.memcpy.html:

  pub unsafe extern fn memcpy(dest: *mut c_void,
                            src: *const c_void,
                            n: size_t)
                            -> *mut c_void


D says https://github.com/dlang/druntime/blob/master/src/core/stdc/string.d#L32:

  pure void* memcpy(return void* s1, scope const void* s2, size_t n);

---

Just from D's type signature, we can know a lot about memcpy():

1. There are no side effects.
2. The return value is derived from s1.
3. Nothing s2 transitively points to is altered via s2.
4. Copies of s1 or s2 are not saved.

The C declaration does not give us any of that info, although the C description
does give us 2, and the 'restrict' says that s1 and s2 do not overlap.

The Rust declaration does not give us 1, 2 or 4 (because it is marked as unsafe). If it was safe, the declaration does not give us 2.

By this information being knowable from the declaration, the compiler knows it too and can make use of it.

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
>
> Just from D's type signature, we can know a lot about memcpy():
>

Yes, D has some notable advantages over other languages, but it also has some notable disadvantages. One in particular prevents me from using D, period! - https://issues.dlang.org/show_bug.cgi?id=14758

Rust has "minimal runtime" as a pillar of its language which makes it very attractive for systems programming.  D will never compete with Rust in that domain if it doesn't lead an effort to do something about it.

Being able to infer implementation characteristics from a function signature is insignificant in comparison.

Mike

On 1/30/2017 5:53 PM, Mike wrote:
> One in particular prevents me from using D, period! -
> https://issues.dlang.org/show_bug.cgi?id=14758

The -betterC switch is the approach we intend to take to deal with that issue.

On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote:
> On 1/30/2017 5:53 PM, Mike wrote:
>> One in particular prevents me from using D, period! -
>> https://issues.dlang.org/show_bug.cgi?id=14758
>
> The -betterC switch is the approach we intend to take to deal with that issue.

I recommend against that; it's too blunt of an instrument.  Instead I suggest following through on things like https://issues.dlang.org/show_bug.cgi?id=12270 and considering this proposal (http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org) instead.

Mike

On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote:
> On 1/30/2017 5:53 PM, Mike wrote:
>> One in particular prevents me from using D, period! -
>> https://issues.dlang.org/show_bug.cgi?id=14758
>
> The -betterC switch is the approach we intend to take to deal with that issue.

You aren't dealing with anything. Your compiler doesn't even target the single biggest embedded platform

On 31/01/2017 3:58 PM, Jaded Observer wrote:
> On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote:
>> On 1/30/2017 5:53 PM, Mike wrote:
>>> One in particular prevents me from using D, period! -
>>> https://issues.dlang.org/show_bug.cgi?id=14758
>>
>> The -betterC switch is the approach we intend to take to deal with
>> that issue.
>
> You aren't dealing with anything. Your compiler doesn't even target the
> single biggest embedded platform

Nobody is going to waste their time adding ARM support to dmd-be. Especially with ldc and gdc which already do.

Now if we were to rewrite dmd-be and made sure there was no legality issues for Walter then maybe we can consider more targets into the reference compiler and more importantly non-OS based targets like MCU's and kernel development.

Until then however, making dmd itself work for both kernel and user space development for x86(_64) seems like a good idea and can be reused for other compilers such as ldc and gdc.

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:

> Rust:
>   pub unsafe extern fn memcpy(dest: *mut c_void,
>                             src: *const c_void,
>                             n: size_t)
>                             -> *mut c_void

> D:
>   pure void* memcpy(return void* s1, scope const void* s2, size_t n);

> 2. The return value is derived from s1.

How can we be sure that the return value points to the same content as `s1`? If that is what you mean by "derived".

> The Rust declaration does not give us 1, 2 or 4 (because it is marked as unsafe). If it was safe, the declaration does not give us 2.

I don't see how Rust doesn't provide information 2 aswell. Is it because of differences in the meaning of `const` in Rust compared to D?

On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote:
> How can we be sure that the return value points to the same content as `s1`? If that is what you mean by "derived".

Now that we allow allocation functions to be `pure` as in

https://github.com/dlang/druntime/pull/1746

On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote:
>
> How can we be sure that the return value points to the same content as `s1`?
Because of the return attribute.
return means I am passing this value through myself.

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
> 3. Nothing s2 transitively points to is altered via s2.

Wait, really? Does that mean that this code is implicitly illegal?

import core.stdc.string;

    void main()
    {
        int*[10] data1;
        int*[10] data2;

        memcpy(data1.ptr, data2.ptr, 10);
    }

Since memcpy is @system, I have no way to know for sure (the compiler obviously won't warn me since I can't mark main as @safe), so I'd argue the prototype doesn't carry that information.