August 09, 2012
On 2012-08-09 15:02, Johannes Pfau wrote:

> What annoys me is that as long the function only supported arrays, it
> didn't need templates _at all_. So template bloat for arrays = 0. But
> adding range support means the version dealing with arrays now has to
> be a template as well(which is probably a bug, can't overload template
> and non template function) and will produce extra code for every array
> type. I just think adding range support shouldn't cause the array code
> to change in any way.

A workaround is to make the non-template function to a template, with no arguments. This should only cause one instantiation:

void foo (T) (T t) if (/* some constraint making it not match "int" */);
void foo () (int x);

-- 
/Jacob Carlborg
August 09, 2012
On 09-Aug-12 14:15, Regan Heath wrote:
> On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see@klickverbot.at>

> If the range/hash object stores the current state and returns this as
> the result of hashreduce, it would be chainable.  If it also had a
> "Digest" property/method which performed finish on a /temporary copy/ of
> the state it would almost be as automatic as reduce.  There would still
> be a manual step to get the result, but it would be analogous to calling
> toString on any range object to output it's "value".  The Digest
> property/method would not modify the internal state, and could be called
> at any time between (not sure there is a point to this) or after chained
> hashreduce operations.

struct ShaState
{
	...
	alias ubyte[16] getDidgest();
}

Problem is: too much magic, spoils auto x = reduce(...); idiom.

To be brutally honest I don't see what in std.hash doesn't fit "range component" model:
	- it works on input ranges via convenient adaptor (or would work soon)
	- it has output _ranges_.

What's not to like about it? That it doesn't fit general reduce algorithm? I'm not convinced it's important. In the same vane you may try to shoehorn symmetric cyphers to follow map interface because conceptually it does 1:1 conversion.

Now important thing: just look at other output ranges.
They either require extra call (see Appender .data) or horrendously slow and ugly see lockingTextWriter/Reader.

-- 
Dmitry Olshansky
August 09, 2012
On 09-Aug-12 20:32, Dmitry Olshansky wrote:
> On 09-Aug-12 14:15, Regan Heath wrote:
>> On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see@klickverbot.at>
>
>> If the range/hash object stores the current state and returns this as
>> the result of hashreduce, it would be chainable.  If it also had a
>> "Digest" property/method which performed finish on a /temporary copy/ of
>> the state it would almost be as automatic as reduce.  There would still
>> be a manual step to get the result, but it would be analogous to calling
>> toString on any range object to output it's "value".  The Digest
>> property/method would not modify the internal state, and could be called
>> at any time between (not sure there is a point to this) or after chained
>> hashreduce operations.
>
> struct ShaState
> {
>      ...
>      alias ubyte[16] getDidgest();
> }

Too fast.. should have been:
	ubyte[16] getDidgest();
	alias getDigest this;

-- 
Dmitry Olshansky
August 09, 2012
On Thursday, 9 August 2012 at 16:37:57 UTC, Dmitry Olshansky wrote:
> Too fast.. should have been:
> 	ubyte[16] getDidgest();
> 	alias getDigest this;

I have been thinking about using AliasThis as well, but the problem is that precisely the use case this is meant to enable (i.e. »snapping together components«, like Walter said) tends to get broken in subtle ways due to the use of template functions/type inference.

David
August 09, 2012
On Thursday, August 09, 2012 18:46:59 David Nadlinger wrote:
> On Thursday, 9 August 2012 at 16:37:57 UTC, Dmitry Olshansky
> 
> wrote:
> > Too fast.. should have been:
> > ubyte[16] getDidgest();
> > alias getDigest this;
> 
> I have been thinking about using AliasThis as well, but the problem is that precisely the use case this is meant to enable (i.e. »snapping together components«, like Walter said) tends to get broken in subtle ways due to the use of template functions/type inference.

Yeah. alias this can be very useful, but it's very dangerous when it comes to templated functions, because it's very easy to make assumptions when writing those functions which hold great when using the actual type but do funny things when alias this comes into play. And unfortunately, I don't think that it's something that's at all well understood. It's probably one of those things that we as a community need to get a better grip on. Just imagine how bad it would be though if D allowed as many implicit conversions as C++ does...

- Jonathan M Davis
August 10, 2012
I implemented some of the suggestions, here's the list of changes:

Changelog:
* Add a new overload to the 'digest' function which accepts an
  InputRange
* Add a new convenience function 'hexDigest' which works just like
  'digest', but returns a string (also works with InputRanges)

  An open question is whether md5StringOf/md5HexOf aliases should be
  added (similar to md5Of)?
* Add a new convenience function 'startDigest' which returns an
  initialized digest
* New example for file hashing in idiomatic D
* Documented that Digests are always OutputRanges
* Added new examples using std.algorithm.copy & OutputRange interface
* Small optimization in toHexString & hexDigest: do not allocate if
  possible

TODO:
* move the package to std.digest (unless there are objections):
    std.hash.hash --> std.digest.digest
    std.hash.md   --> std.digest.md
    std.hash.sha  --> std.digest.sha
    std.hash.crc  --> std.digest.crc

* make sure the docs are consistent regarding names (digest vs. hash)


Code:
https://github.com/jpf91/phobos/tree/newHash/std/hash
https://github.com/jpf91/phobos/compare/master...newHash

Docs: http://dl.dropbox.com/u/24218791/d/phobos/std_hash_hash.html http://dl.dropbox.com/u/24218791/d/phobos/std_hash_md.html http://dl.dropbox.com/u/24218791/d/phobos/std_hash_sha.html http://dl.dropbox.com/u/24218791/d/phobos/std_hash_crc.html
August 12, 2012
See the new thread Andrei started entitled "finish function for output ranges". I think this discussion has clearly discovered a shortcoming in the current range design, and Andrei has a proposed solution.
August 15, 2012
On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote:
>> In this case, it needs to work like a reduce algorithm, because it is a reduce algorithm. Need to find a way to make this work.
>
> Hash functions are _not_ analogous to reduce(), because the operation performed by reduce() is stateless, whereas hash functions generally have some internal state.

An example of stateless hash in .net:
http://msdn.microsoft.com/en-us/library/xa627k19.aspx
August 15, 2012
On 15-Aug-12 11:41, Kagamin wrote:
> On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote:
>>> In this case, it needs to work like a reduce algorithm, because it is
>>> a reduce algorithm. Need to find a way to make this work.
>>
>> Hash functions are _not_ analogous to reduce(), because the operation
>> performed by reduce() is stateless, whereas hash functions generally
>> have some internal state.
>
> An example of stateless hash in .net:
> http://msdn.microsoft.com/en-us/library/xa627k19.aspx

AFAIK it'a method of HashAlgorithm Object.

http://msdn.microsoft.com/en-us/library/c06s9c55

It also includes TransformBlock & TransformFinalBlock. It does contain state of course.

August 15, 2012
On Wednesday, 15 August 2012 at 07:41:20 UTC, Kagamin wrote:
> On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote:
>> Hash functions are _not_ analogous to reduce(), because the operation performed by reduce() is stateless, whereas hash functions generally have some internal state.
>
> An example of stateless hash in .net:
> http://msdn.microsoft.com/en-us/library/xa627k19.aspx

http://msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.state

David