On Monday, March 12, 2012 11:25:41 H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 02:10:23PM -0400, Jonathan M Davis wrote:
> > On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote:
> > > Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all.
> > 
> > D doesn't make writing unit tests easy, since there's an intrinsic amount of effort required to write them, just like there is with any code, but it takes away all of the extraneous effort in having to set up a unit test framework and the like. And by removing pretty much anything from the effort which is not actually required, it makes writing unit testing about as easy as it can be.
> 
> I would argue that D *does* make unit tests easier to write, in that you can write them in straight D code inline (as opposed to some testing frameworks that require external stuff like Expect, Python, intermixed with native code), so you don't need to put what you're writing on hold while you go off and write unittests. You can just insert a unittest block after the function/class/etc immediately while the code is still fresh in your mind. I often find myself writing unittests simultaneously with real code, since while writing the code I see a possible boundary condition to test for, and immediately put that in a unittest to ensure I don't forget about it later. This improves the quality of both the code and the unittests.

I didn't say that D doesn't make writing unit tests easier. I just said that it doesn't make them _easy_. They're as much work as writing any code is. But by making them easier, D makes them about as easy to write as they can be.

Regardless, built-in unit testing is a fantastic feature.

- Jonathan m Davis

> Because that requires having all of the source code. The fact that we have .di
> files prevents that.
It doesn't require all source code.
It just means that without source code nothing can be inferred and the
attributes fall back to what has been annotated by hand.
It could be used to annotated functions at the API level and have
the compiler check that transitively.
It should behave like implicit conversion to "pure nothrow ..." if the
compiler hasn't found them inapplicable.

On the downside it has some implications for the compilation model
because functions would need to be analyzed transitively.
But then again we already do this for CTFE.

On 03/12/2012 09:46 PM, Jonathan M Davis wrote:
> On Monday, March 12, 2012 21:36:21 Martin Nowak wrote:
>>> That could be solved with a @ctfe attribute or something, no? Like, if
>>> the function has @ctfe, go through all possible CTFE paths (excluding
>>> !__ctfe paths of course) and make sure they are CTFEable.
>>
>> Everything that's pure should be CTFEable which doesn't imply that you
>> can turn every CTFEable function into a pure one.
>
> I don't think that that's quite true. pure doesn't imply @safe, so you could
> do pointer arithmetic and stuff and the like - which I'm pretty sure CTFE won't
> allow. And, of course, if you mark a C function as pure or subvert pure
> through casts, then pure _definitely_ doesn't imply CTFEability.
>
> - Jonathan M Davis

CTFE allows quite some pointer arithmetic, but makes sure it is actually safe.

On 3/12/2012 1:56 PM, Martin Nowak wrote:
> It doesn't require all source code.
> It just means that without source code nothing can be inferred and the
> attributes fall back to what has been annotated by hand.

Hello endless bug reports of the form:

"It compiles when I send the arguments to dmd this way but not that way. dmd is broken. D sux."

On 3/12/2012 4:11 AM, deadalnix wrote:
> For struct, we have inference,

? No we don't.

> so most of the time attributes will correct.
> const pure nothrow @safe are something we want, but is it something we want to
> enforce ?

Yes, because they are referred to by TypeInfo, and that's fairly useless if it isn't const etc.

On 3/12/2012 11:10 AM, Jonathan M Davis wrote:
> I believe that Walter likes to say that it takes away your excuse _not_ to
> write them because of how easy it is to write unit tests in D.

It can be remarkable how much more use something gets if you just make it a bit more convenient.

On 11/03/2012 23:54, Walter Bright wrote:
> Consider the toHash() function for struct key types:
>
> http://dlang.org/hash-map.html
>
> And of course the others:
>
> const hash_t toHash();
> const bool opEquals(ref const KeyType s);
> const int opCmp(ref const KeyType s);
<snip>

And what about toString?

Stewart.

On Tuesday, March 13, 2012 01:15:59 Stewart Gordon wrote:
> On 11/03/2012 23:54, Walter Bright wrote:
> > Consider the toHash() function for struct key types:
> > 
> > http://dlang.org/hash-map.html
> > 
> > And of course the others:
> > 
> > const hash_t toHash();
> > const bool opEquals(ref const KeyType s);
> > const int opCmp(ref const KeyType s);
> 
> <snip>
> 
> And what about toString?

That really should be too, but work is probably going to have to be done to make sure that format and std.conv.to can be pure, since they're pretty much required in most toString functions.

I believe that changes to toUTF8, toUTF16, and toUTF32 were made recently which are at least a major step in that direction for std.conv.to (since it uses them) and may outright make it so that it can be pure now (I'm not sure if anything else is preventing them from being pure). But I have no idea what the current state of format is with regards to purity, and if the changes to toUTFx weren't enough to make std.conv.to pure for strings, then more will need to be done there as well.

- Jonathan M Davis

Stewart Gordon:

> And what about toString?

Often in toString I use format() or text(), or to!string(), that currently aren't pure nor nothrow.

But in this thread I have seen no answers regarding deprecating the need of opCmp() for hashability.

Bye,
bearophile

On 13-03-2012 02:28, bearophile wrote:
> Stewart Gordon:
>
>> And what about toString?
>
> Often in toString I use format() or text(), or to!string(), that currently aren't pure nor nothrow.
>
> But in this thread I have seen no answers regarding deprecating the need of opCmp() for hashability.
>
> Bye,
> bearophile

I fully support that.

-- 
- Alex