View mode: basic / threaded / horizontal-split · Log in · Help
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
> 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.
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @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."
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
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
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home