Am Mon, 11 Jun 2018 10:54:23 +0000 schrieb Mike Franklin: > On Monday, 11 June 2018 at 10:38:30 UTC, Mike Franklin wrote: >> On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote: >> >>>> I think there might also be optimization opportunities using >>>> templates, metaprogramming, and type introspection, that are not >>>> currently possible with the current design. >>> >>> Just making it a template doesn't automatically enable any of this. >> >> I think it does, because I can then generate specific code based on the >> type information at compile-time. > > Also, before you do any more nay-saying, you might want to revisit this > talk https://www.youtube.com/watch?v=endKC3fDxqs which demonstrates > precisely the kind of benefits that can be achieved with these kinds of > changes to the compiler/runtime interface. > > Mike
I guess for most D runtime hooks, using templates is a good idea to enable inlining and further optimizations. I understand that you actually need to reimplement memcpy, as in your microcontroller usecase you don't want to have any C runtime. So you'll basically have to rewrite the C runtime parts D depends on. However, I think for memcpy and similar functions you're probably better off keeping the C interface. This directly provides the benefit of compiler intrinsics/optimizations. And marking memcpy as nothrow/pure/ system/nogc is simple* either way. For the D implementation, the compiler will verify this for you, for the C implementation, you have to mark the function depending on the C implementation. But that's mostly trivial. On a related note, I agree that the compiler sometimes cheats by ignoring attributes, especially when calling TypeInfo related functions, and this is a huge problem. Runtime TypeInfo is not descriptive enough to fully represent the types and whenever the compiler the casts without properly checking first, there's the possibility of a problem. -- Johannes