On Thursday, 27 March 2014 at 21:54:00 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 1:58 PM, Walter Bright wrote:
On 3/27/2014 12:50 PM, Andrei Alexandrescu wrote:
Yah, agreed. -- Andrei
Completely unworkable. To determine if a range is empty or
not, it may
have to actually read from its inpu
On Thursday, 16 August 2012 at 03:02:59 UTC, RivenTheMage wrote:
ushort num = 1234;
auto hash1 = hash!("(a >>> 20) ^ (a >>> 12) ^ (a >>> 7) ^ (a >>>
4) ^ a")(str); // indexing hash
I forgot that this case is already covered by reduce!(...)
On Wednesday, 15 August 2012 at 19:38:34 UTC, José Armando
García Sancio wrote:
Thats because it is a "password module" and nobody or a small
percentage of the population uses CRC for password digest.
In turn, that's because CRC is not not a crytographic hash and
not suited for password hashin
Another example is a systematic error-correcting codes. The
"only" difference between them and checksums is the ability to
correct errors, not just detect them. CRC or MD5 can be viewed as
systematic code with zero error-correcting ability.
Should we mix Reed-Solomon codes and MD5 in one module?
On Wednesday, 15 August 2012 at 08:55:30 UTC, David Nadlinger
wrote:
Why? 1) might have a different interface than the others, but
2) and 3) only differ in their cryptological properties, the
interface will likely be just the same – or what are you
thinking about?
David
The "only" differen
On Wednesday, 8 August 2012 at 16:47:35 UTC, Johannes Pfau wrote:
std.hash.digest doesn't sound too bad. We could have
std.hash.func (or
a better named module ;-) for general hash functions later.
Three basic types of hash functions are:
1) Hash - for fast searching and indexing in data stru
On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:
Going to v3 would mean incrementing the 2.
We have _no_ intention of doing that for years
to come.
Small steps are perfect for many projects, but - in my opinion -
not for a programming language specification (and reference
impl
On Monday, 16 July 2012 at 21:29:39 UTC, SomeDude wrote:
That's very precisely what the "rename" function of IDEs like
eclipse do, BTW.
The "upgrade mode" should be more than just textual
search-and-replace.
On Monday, 16 July 2012 at 20:45:11 UTC, SomeDude wrote:
This way, the stable branch and the dev branch don't diverge to
the point that there effectively become two versions of the
same language.
I think, they should be diverging.
The stable branch should be "the TDPL branch". After reaching
On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:
Changing names is minute progress, and is too costly in terms
of annoying existing users and breaking their code.
Cost can be lowered - by introducing (semi-)automatic
refactoring/upgrade mode.
dmd -upgrade zzz.d
Compiler can do
On Thursday, 12 July 2012 at 13:35:54 UTC, Roman D. Boiko wrote:
OK, I found one myself from this post:
http://michelf.com/weblog/2012/mutex-synchonization-in-d/
Beat me :)
On Thursday, 12 July 2012 at 12:43:01 UTC, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
The fact that every object has a monitor associated with it
was a
mistake in Java, and was unfortunately copied in .NET. This
promotes the bad practice of locking
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
Jon Skeet wrote on this long ago:
http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx
The fact that every object has a monitor associated with it was a
mistake in Java, and was un
The problem is that while in most cases, separating getting the
element referred to by the iterator (or the front of the range)
separately
from iterating is more efficient than having the iterator
return an element when
you iterate it
Yes, but iterators don't need that separation at all. AFAI
Currently I think that idea was very bad, given that it would
be difficult to find all ranges which invalidate previous front
value on popFront.
It seems, consumeFront() is attempt to implement a forward
iterator on top of a range. Maybe the problem is mixing up two
different abstractions.
On Saturday, 26 May 2012 at 06:06:08 UTC, sclytrack wrote:
On 05/26/2012 06:58 AM, jerro wrote:
On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote:
Why not just call it 'destroy()'?
+1
+1
+1
On Wednesday, 28 March 2012 at 22:23:51 UTC, Manu wrote:
Although I'm not sure why you distinguish 'metainfo' from
'meta'?
To me, it's consistent with .typeinfo and .classinfo properties.
My proposal:
http://www.digitalmars.com/d/archives/digitalmars/D/Yet_another_compile-time_reflection_revisited_proposal_150309.html
On Wednesday, 21 March 2012 at 12:37:50 UTC, Mantis wrote:
Builtin annotations' names are not reserved keywords, so this
would be possible and ambiguous:
string safe( string s );
@safe void foo(); // what @safe stands for?
What about "@" for built-in annotations and "@!" for user-defined?
@!
On Monday, 19 March 2012 at 00:41:44 UTC, Walter Bright wrote:
Maybe this is why I don't much care for attributes - it's all
just a fog to me what is happening.
Maybe this will help:
http://research.microsoft.com/en-us/um/people/cszypers/events/WCOP2006/rouvoy-wcop-06.pdf
Attribute-Oriented
On Wednesday, 14 March 2012 at 02:33:29 UTC, Kevin Cox wrote:
Kind of unrelated but I think that it is important to have a
way to ignore
values also. Leaving them bank would sufice.
(int i,,float f) = intBoringFloat();
or
(int i, null, float f) = intBoringFloat();
or
(int i, void, float f
So, function with MRV is basically the function that returns
Tuple where one can specify return convention?
---
auto fun()
{
return(Windows) tuple(1, 2.0f);
}
(int x, float y) = fun();
---
> Short term and long term suggestions ? Anything we can do ?
I'm using UniLink.
> import std.stdio;
> int main(){
> writefln("Hello Bloat!");
> return 0;
> }
On Windows:
DMD v2.056
UniLink 1.07 build 3.21
---
import std.stdio;
int main()
{
writefln("Hello World!");
return 0;
}
---
dmd.ex
> Yes, __traits should be replaced by a cleaner design eventually.
> 'is'-expressions, typeid and std.traits are perfectly fine as they are
> now and I don't see any reason to make their syntax more complicated.
Before all, why typeid() is named typeID()? The return type is TypeInfo :)
On 30.11.2011 1:29:16, Jacob Carlborg wrote:
> It would be good if "compiles" could be a block, but that would be
> inconsistent with the rest. Something like this:
>
> meta.compiles
> {
> // code
> }
It can be allowed to pass string as argument (just like in string mixins).
And then:
meta.comp
*1) Replace all symbol-related traits with ".metainfo" property*
__traits(isAbstractClass, A) ==> A.metainfo.isAbstractClass
__traits(A.func, isVirtualFunction) ==>
by name: A.metainfo.members["func"].isVirtualFunction
by index: A.metainfo.members[N].isVirtualFunction
__traits(hasMember, A, "fu
http://d-programming-language.org/new/
There is an error, I believe: "scope statements" link should point to
#ScopeGuardStatement, not #ScopeBlockStatement.
If using multiple paradigms is reasonably natural and convenient in that
language.
D: imperative, OOP, metaprogramming, functional, assembler, script
Zero-paradigm?
In the sense that the D language supports almost all popular paradigms.
> auto fun(return(type) a, ...)
auto fun(ret a, ...) ?
29 matches
Mail list logo
