On 2/1/2017 1:47 PM, Adam D. Ruppe wrote:
> At the rate D is going, pretty soon the entire function body will be retold in
> the signature. What's the point when it is obvious that in practice, we can
> actually analyze the content and get BETTER coverage anyway?

It already does this for templates and function literals.

It's not really possible for C headers :-)

On Wednesday, 1 February 2017 at 21:47:58 UTC, Adam D. Ruppe wrote:
> (actually in the real world, it won't since nobody will care enough to write `pure public return const(T) hi(return scope T t) nothrow @nogc @safe @noincompetence @a_million_other_things { return t; }`)

I found all the attribution of function definitions a little unnerving when I started learning D, but at least one other believed it was idiomatic D.

It makes me wonder if D has the wrong defaults (though probably a moot point if changing it would break code).  But, it does place D at a disadvantage to a language like Rust, where one has to opt-out of safety, while in D it appears to be opt-in.

Mike

On Wed, Feb 01, 2017 at 11:49:25PM +0000, Mike via Digitalmars-d wrote:
> On Wednesday, 1 February 2017 at 21:47:58 UTC, Adam D. Ruppe wrote:
> > (actually in the real world, it won't since nobody will care enough
> > to write `pure public return const(T) hi(return scope T t) nothrow
> > @nogc @safe @noincompetence @a_million_other_things { return t; }`)
> 
> I found all the attribution of function definitions a little unnerving when I started learning D, but at least one other believed it was idiomatic D.

I think the goal, if it's possible to attain to eventually, is to have the compiler infer most of the attributes, ideally all.  This is already done for a good number of attributes for template functions and auto functions.  I agree with you that attribute soup is a Bad Thing for a language.


> It makes me wonder if D has the wrong defaults (though probably a moot point if changing it would break code).  But, it does place D at a disadvantage to a language like Rust, where one has to opt-out of safety, while in D it appears to be opt-in.
[...]

We would love to change the defaults, but unfortunately that boat has already sailed a long time ago.  If we could do it all over again, I'm sure a lot of defaults would be the opposite of what they are today. But we can't reasonably change that now without massive breakage of current code.


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan

On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
> On Wed, Feb 01, 2017 at 11:49:25PM +0000, Mike via Digitalmars-d wrote:
>> On Wednesday, 1 February 2017 at 21:47:58 UTC, Adam D. Ruppe wrote:
>> > (actually in the real world, it won't since nobody will care enough
>> > to write `pure public return const(T) hi(return scope T t) nothrow
>> > @nogc @safe @noincompetence @a_million_other_things { return t; }`)
>> 
>> I found all the attribution of function definitions a little unnerving when I started learning D, but at least one other believed it was idiomatic D.
>
> I think the goal, if it's possible to attain to eventually, is to have the compiler infer most of the attributes, ideally all.
>  This is already done for a good number of attributes for template functions and auto functions.  I agree with you that attribute soup is a Bad Thing for a language.
>
A different spin on the same topic - I've been wondering what the anticipated changes to both the standard library and application code are going to be as a result of dip25 and dip1000. Is the expectation that use of the new annotations will be limited to select portions of code bases, or that they will become the predominant way to write D code?

Another spin - If a company has a team people building a code-base and decides to establish best practices, how might the facilities introduced by dip25 and dip1000 fit into those best practices?

Clearly, there will be a menu of options available to teams, applications, etc. But, I would expect there to be a small number of preferred, commonly adopted approaches. And, it would be preferable, though not necessary, that best practices and idioms used in the standard library were a good starting point for new adoptees and development efforts. Hence my question about both Phobos and application code.

Perhaps it's too early to answer these questions, but if there are expected outcomes it would be useful to understand them.

--Jon

Walter Bright <newshound2@digitalmars.com> wrote:
> On 2/1/2017 9:22 AM, Tobias Müller wrote:
>> You wouldn't use memcpy but just assign the slices.
> 
> I clearly made a mistake in this example. I wanted to show how a compiler learns things from the declaration by using a very familiar declaration. But it keeps getting diverted into what people (and some compilers) "know" about memcpy that is not in the declaration.

I also showed you how memcpy could look like in Rust, I think it's only fair to also point out that this would be fairly unidiomatic.

Apart from that, the entire point of building a safe wrapper around an
unsafe FFI function is to exploit additional knowledge that is not present
in the C declaration, but only in documentation. It's not relevant if that
wrapper is built into the language or a library function.
After all, to write the D declaration you also had to exploit that
knowledge once.

Walter Bright <newshound2@digitalmars.com> wrote:
> On 2/1/2017 9:28 AM, Michael Howell wrote:
>> unsafe fn copy_nonoverlapping_ref<T>(src: &T, dest: &mut T, len: usize) {
>> std::ptr::copy_nonoverlapping(src, dest, len)
>> }
>> 
>> Again, it doesn't guarantee no side effects, it may guarantee that src isn't mutated, it does guarantee that they aren't stored away somewhere, and it guarantees that src and dest don't overlap.
> 
> What part of the signature guarantees non-overlap?

Mutable references cannot overlap in Rust, at least in safe code.
The exact guarantees in unsafe code are not yet clear and currently being
fleshed out.
OTOH using unsafe code in Rust is quite rare.

On 2/1/2017 10:11 PM, Tobias Müller wrote:
> Apart from that, the entire point of building a safe wrapper around an
> unsafe FFI function is to exploit additional knowledge that is not present
> in the C declaration, but only in documentation. It's not relevant if that
> wrapper is built into the language or a library function.

D won't make you add annotations. You can use Valgrind or gdb if you prefer.

On 2/1/2017 10:23 PM, Tobias Müller wrote:
> Walter Bright <newshound2@digitalmars.com> wrote:
>> What part of the signature guarantees non-overlap?
> Mutable references cannot overlap in Rust, at least in safe code.

I didn't know that bit, thanks for the info.

On Wednesday, 1 February 2017 at 21:16:30 UTC, Walter Bright wrote:
> 6. Valgrind isn't available on all platforms, like Windows, embedded systems, phones (?), etc.

You can use valgrind on embedded systems as long as they run a GNU/Linux OS. I've used valgrind successfully many times on ARM architecture.
But I don't know if it works with Android, and I doubt it works on baremetal indeed.

On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
> On Wed, Feb 01, 2017 at 11:49:25PM +0000, Mike via
>
> We would love to change the defaults, but unfortunately that boat has already sailed a long time ago.  If we could do it all over again, I'm sure a lot of defaults would be the opposite of what they are today. But we can't reasonably change that now without massive breakage of current code.
>
>
> T

My opinion is that the current situation is not that bad: it's some sort of bottom-up approach.

Almost always, in a company, programmers are under time pressure and rushing, so I bet that almost always they will add a @system: on the top of the module.

Maybe not true, but It come in my mind the Java "throw Exception" parade in function declaration....

/Paolo