The discussion around new unified API for digest hash functions
has subdued, just in time as the review period has ended.
The voting for std.digest package starts today and ends on 29
August.
Rules are simple: reply in this thread with definite "YES" or
"NO" on whether this package should go
On 27 August 2012 02:06, Andrei Alexandrescu
wrote:
> On 8/26/12 1:32 PM, Johannes Pfau wrote:
>
>> Seems some people would rather want to keep auto in the examples. I'm
>> not sure what to do about this. I never used auto return types, so the
>> return type can be looked up in the documentation b
Am Fri, 24 Aug 2012 17:49:00 +0200
schrieb "d_follower" :
>
> But I'd like to see at least one algorithm being implemented
> (e.g. CRC32 which currently works with CTFE) as a proof of
> concept (and a unit-test).
Proof of concept:
http://dpaste.dzfl.pl/b14e8aad
As you can see the templated di
Am Mon, 27 Aug 2012 01:49:12 +0300
schrieb Manu :
> Though that said, looking at the API doc for finish(), it appears to
> return a dynamic array, not a static array as you say... so ubyte[]
> could be used everywhere, and that would be nice and clear?
>
That's the Digest / OOP APIs finish metho
Am Sun, 26 Aug 2012 23:57:24 +0400
schrieb Dmitry Olshansky :
> On 26-Aug-12 19:11, Andrei Alexandrescu wrote:> On 8/22/12 8:36 AM,
> Dmitry Olshansky wrote:
> >> The discussion around new unified API for digest hash functions
> >> has subdued, just in time as the review period has ended.
> >>
On 8/26/12 7:14 AM, Andrei Alexandrescu wrote:
How about this - use auto for code samples, but not for documenting
function return types (except Voldemort)?
Pie-in-the-sky dream: DDOC would advance enough to show a hover hint
over the "auto" keyword with the computed type.
On Tue, Aug 28, 2012 at 1:19 AM, David Gileadi wrote:
> On 8/26/12 7:14 AM, Andrei Alexandrescu wrote:
>
>> How about this - use auto for code samples, but not for documenting
>> function return types (except Voldemort)?
>>
>
> Pie-in-the-sky dream: DDOC would advance enough to show a hover hint o
On 8/26/2012 7:14 AM, Andrei Alexandrescu wrote:
On 8/26/12 8:35 AM, Craig Dillabaugh wrote:
On Sunday, 26 August 2012 at 10:32:37 UTC, Mike James wrote:
+2
As a very inexperienced D user, I find the use of auto in the
documentation frustrating too.
Cheers,
Craig
I'm torn on this. The argume
On Sunday, 26 August 2012 at 10:32:37 UTC, Mike James wrote:
"Manu" wrote in message
news:mailman.1410.1345976415.31962.digitalmar...@puremagic.com...
Looks good, though one thing annoys me as always throughout the
D docs, liberal use of auto can make them very difficult to
understand.
auto
On 2012-08-28 23:29, Walter Bright wrote:
I think there need to be explicit types in the doc so people can click
on a link to them and see what they are.
I should work with "auto" as well.
--
/Jacob Carlborg
On 2012-08-26 12:19, Manu wrote:
Looks good, though one thing annoys me as always throughout the D docs,
liberal use of auto can make them very difficult to understand.
auto result = hash.finish();
From the examples where this appears, I have absolutely no idea what
'result' could possibly be
Dmitry Olshansky wrote:
> The discussion around new unified API for digest hash functions has
> subdued, just in time as the review period has ended.
>
> The voting for std.digest package starts today and ends on 29
> August.
>
> Rules are simple: reply in this thread with definite "YES" or "NO"
On Wednesday, 22 August 2012 at 12:36:08 UTC, Dmitry Olshansky
wrote:
The discussion around new unified API for digest hash functions
has subdued, just in time as the review period has ended.
The voting for std.digest package starts today and ends on 29
August.
Rules are simple: reply in thi
On Wednesday, 22 August 2012 at 12:36:08 UTC, Dmitry Olshansky
wrote:
The discussion around new unified API for digest hash functions
has subdued, just in time as the review period has ended.
Yes.
d_follower wrote:
> On Wednesday, 22 August 2012 at 12:36:08 UTC, Dmitry Olshansky
> wrote:
> >The discussion around new unified API for digest hash functions
> >has subdued, just in time as the review period has ended.
> >
> >The voting for std.digest package starts today and ends on 29
> >August.
Yes.
The API seems fairly solid to me, and the
need for these things is fairly wide reaching.
Am Thu, 23 Aug 2012 22:46:35 +0200
schrieb Jens Mueller :
>
> It says "Digests do not work in CTFE".
> Just checked it for MD5.
> I do not know but I think this is just a current limitation of the
> CTFE implementation.
It's possible to support CTFE, Piotr Szturmaj has some digests which
work in
Johannes Pfau wrote:
> Am Thu, 23 Aug 2012 22:46:35 +0200
> schrieb Jens Mueller :
>
> >
> > It says "Digests do not work in CTFE".
> > Just checked it for MD5.
> > I do not know but I think this is just a current limitation of the
> > CTFE implementation.
>
> It's possible to support CTFE, Piot
Yes
On Friday, 24 August 2012 at 08:18:07 UTC, Johannes Pfau wrote:
Am Thu, 23 Aug 2012 22:46:35 +0200
schrieb Jens Mueller :
It says "Digests do not work in CTFE".
Just checked it for MD5.
I do not know but I think this is just a current limitation of
the
CTFE implementation.
It's possible to
Yes
---
Oleg
Looks good, though one thing annoys me as always throughout the D docs,
liberal use of auto can make them very difficult to understand.
auto result = hash.finish();
>From the examples where this appears, I have absolutely no idea what
'result' could possibly be and what I can do with it, and you'
"Manu" wrote in message
news:mailman.1410.1345976415.31962.digitalmar...@puremagic.com...
Looks good, though one thing annoys me as always throughout the D docs, liberal
use of auto can make them very difficult to understand.
auto result = hash.finish();From the examples where this appears, I
On Sunday, 26 August 2012 at 10:32:37 UTC, Mike James wrote:
"Manu" wrote in message
news:mailman.1410.1345976415.31962.digitalmar...@puremagic.com...
Looks good, though one thing annoys me as always throughout the
D docs, liberal use of auto can make them very difficult to
understand.
auto
Am Sun, 26 Aug 2012 13:19:35 +0300
schrieb Manu :
> Looks good, though one thing annoys me as always throughout the D
> docs, liberal use of auto can make them very difficult to understand.
>
> auto result = hash.finish();
>
> >From the examples where this appears, I have absolutely no idea what
On 8/26/12 8:35 AM, Craig Dillabaugh wrote:
On Sunday, 26 August 2012 at 10:32:37 UTC, Mike James wrote:
+2
As a very inexperienced D user, I find the use of auto in the
documentation frustrating too.
Cheers,
Craig
I'm torn on this. The arguments make sense; on the other hand, people
will in
Andrei Alexandrescu:
I'm torn on this. The arguments make sense; on the other hand,
people will in all likelihood write their own code in the style
promoted by the doc examples.
How about this - use auto for code samples, but not for
documenting function return types (except Voldemort)?
Ge
One more thing - for future work, it would be great to have a function a
la mcookie, see http://linux.about.com/library/cmd/blcmdl1_mcookie.htm.
Andrei
On 8/22/12 8:36 AM, Dmitry Olshansky wrote:
The discussion around new unified API for digest hash functions has
subdued, just in time as the review period has ended.
The voting for std.digest package starts today and ends on 29 August.
Rules are simple: reply in this thread with definite "YES"
On Sunday, August 26, 2012 10:14:14 Andrei Alexandrescu wrote:
> How about this - use auto for code samples, but not for documenting
> function return types (except Voldemort)?
I tend to agree with this. If a function needs to return auto in order to be
reasonable (e.g. it has to because of Volde
Am Sun, 26 Aug 2012 15:43:48 +0200
schrieb Johannes Pfau :
> Am Sun, 26 Aug 2012 13:19:35 +0300
> schrieb Manu :
>
> > Looks good, though one thing annoys me as always throughout the D
> > docs, liberal use of auto can make them very difficult to
> > understand.
> >
> > auto result = hash.finish
Yes.
Yea, I agree that docs shouldn't use auto. It's real pain in ...
I am fine with auto in code examples but in function/method
description the returned type should be clearly pointed out.
On 26-Aug-12 19:11, Andrei Alexandrescu wrote:> On 8/22/12 8:36 AM,
Dmitry Olshansky wrote:
>> The discussion around new unified API for digest hash functions has
>> subdued, just in time as the review period has ended.
>>
>> The voting for std.digest package starts today and ends on 29 August.
>
Yea, I agree that docs shouldn't use auto. It's real pain in ...
I am fine with auto in code examples but in function/method
description the returned type should be clearly pointed out.
I personally only try to use auto where the type is unambiguous.
For example, if I'm calling a function in th
On 26 August 2012 16:43, Johannes Pfau wrote:
> Am Sun, 26 Aug 2012 13:19:35 +0300
> schrieb Manu :
>
> > Looks good, though one thing annoys me as always throughout the D
> > docs, liberal use of auto can make them very difficult to understand.
> >
> > auto result = hash.finish();
> >
> > >From
On 8/26/12 1:32 PM, Johannes Pfau wrote:
Seems some people would rather want to keep auto in the examples. I'm
not sure what to do about this. I never used auto return types, so the
return type can be looked up in the documentation but it's of course
not obvious by just reading the examples.
Af
36 matches
Mail list logo
