On Sun, 15 Feb 2015 18:19:49 -0800, Andrei Alexandrescu wrote:
Folks, we want to get 2.067 out the door on March 1. That's two short
weeks from now. We really need all hands on deck to make this a
successful release.
we can't. this issue, for example, was known for monthes (or, maybe,
https://issues.dlang.org/show_bug.cgi?id=14189
Issue ID: 14189
Summary: can't declare two identical function prototypes
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
https://issues.dlang.org/show_bug.cgi?id=13009
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||pull
--- Comment #9 from
On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Feb 15, 2015 at 07:49:15PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
Just figured that the documentation of package-ized std.algorithm
is... not good:
http://dlang.org/phobos-prerelease/std_algorithm_package.html
It
https://issues.dlang.org/show_bug.cgi?id=14188
Issue ID: 14188
Summary: Add gcc-equivalent -MD options to dmd
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
On Monday, 16 February 2015 at 16:56:15 UTC, Per Nordlöw wrote:
Is there a specific function in to empty a builtin D array or
should I just do
auto x = [1,2,3];
x = [];
I'm asking because std.container.Array has the member .clear()
and I would like my code to compatible with both
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
On Monday, 16 February 2015 at 17:55:42 UTC, Jonathan Marler
wrote:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function
On Mon, 16 Feb 2015 12:16:50 +, rupert wrote:
If you think you could do a better job than the C++ committee you should
submit a proposal.
https://isocpp.org/std/submit-a-proposal
why he *should* to that? he *may* submit it. when someone sees people
doing shit, he is not obliged to
On Monday, 16 February 2015 at 16:00:29 UTC, ketmar wrote:
we can't. this issue, for example, was known for monthes (or,
maybe,
years?), yet there is no sign that it's something that MUST be
fixed for
release.
what i want to tell is that there is no release plan, no
feature freeze
before
Is there a specific function in to empty a builtin D array or
should I just do
auto x = [1,2,3];
x = [];
I'm asking because std.container.Array has the member .clear()
and I would like my code to compatible with both builtin arrays
and std.container.Array. If not is there an con to
On Monday, 16 February 2015 at 17:00:39 UTC, Tobias Pankrath
wrote:
You can set the length to zero for both.
Thanks.
I believe C++ programmers would find a tiny wrapper function, say
clear(), in std.algorithm or perhaps even D array builtin for
this nice from a portability point of view.
https://issues.dlang.org/show_bug.cgi?id=14190
Issue ID: 14190
Summary: Overload sets example incorrect
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: spec
Severity: normal
https://issues.dlang.org/show_bug.cgi?id=7436
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Oh I understood. It's means that it work only of two or more
element's is placed one after one?
On 2/14/15 12:00 PM, Andrei Alexandrescu wrote:
There's been recurring discussion about failing constraints not
generating nice error messages.
void fun(T)(T x) if (complicated_condition) { ... }
struct Type(T)(T x) if (complicated_condition) { ... }
If complicated_condition is not met, the
On 2015-02-16 10:40, Benjamin Thaut wrote:
This is in fact not a breaking change because export is broken anyway.
Due to bug 922 export can't be used in cross platform libraries. I
haven't seen a single library on dub that uses export (most likely for
exactly that reason).
Most likely due to
On Monday, 16 February 2015 at 20:09:09 UTC, Nordlöw wrote:
I'm trying to figure out how to implement a light-weight wrappr
realizing type-safe indexing á lá Ada. Here's my first try:
struct Ix(T = size_t)
{
@safe pure: @nogc nothrow:
this(T ix) { this._ix = ix; }
alias _ix this;
On Monday, 16 February 2015 at 18:45:17 UTC, Suliman wrote:
Oh I understood. It's means that it work only of two or more
element's is placed one after one?
That's why you'll usually want to sort before using uniq.
On Monday, 16 February 2015 at 20:09:09 UTC, Nordlöw wrote:
I'm trying to figure out how to implement a light-weight wrappr
realizing type-safe indexing á lá Ada. Here's my first try:
See also:
https://github.com/nordlow/justd/blob/master/typecons_ex.d#L83
On Monday, 16 February 2015 at 17:58:10 UTC, Benjamin Thaut wrote:
Because the index operator throws a OutOfRange exception and
throwing exceptions allocates, maybe?
Oh...I hadn't thought of that! Thanks for the quick response.
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
// cause GC allocation
}
I have a c++ struct:
template typename retval
struct ezDelegateretval ()
{
}
void DelegateTest(ezDelegatevoid () func) { ... }
And I want to match that on the D side, unfortunately it does not work:
D:
struct ezDelegate(Signature) {}
alias delegate_t = ezDelegate!(void function());
On Monday, 16 February 2015 at 18:45:17 UTC, Suliman wrote:
Oh I understood. It's means that it work only of two or more
element's is placed one after one?
Yes, uniq returns exactly the same range as its input, except
that elemens that are equal to their immediate predecessor are
dropped.
On 2015-02-16 at 18:58, Benjamin Thaut wrote:
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
https://issues.dlang.org/show_bug.cgi?id=14189
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
Status|NEW |RESOLVED
The question appear here
http://stackoverflow.com/questions/28546572/how-to-find-duplicates-in-array-of-strings-in-d
I can't understand, why uniq work for array of int but do not
work with array of strings.
int[] arr = [ 1, 2, 2, 2, 2, 3, 4, 4, 4, 5 ];
writeln(uniq(arr));
Hi.
And how to read Data from the input stream?
import std.stdio;
import std.bigint;
void main() {
BigInt n;
readf( %?, n);
writeln(n);
}
On Mon, 16 Feb 2015 09:36:57 -0800, Andrei Alexandrescu wrote:
* There is no added value to D users in splitting algorithm.d into a
package.
* Even the value to contributors is debatable and definitely low impact.
* The documentation is in shambles.
All told we're looking at a net
https://issues.dlang.org/show_bug.cgi?id=2789
--- Comment #12 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
https://github.com/D-Programming-Language/phobos/commit/41f243a6c29f00ab4cdeb69d418796ed00fa0c51
Supplemental fix for
On Monday, 16 February 2015 at 18:28:13 UTC, Suliman wrote:
The question appear here
http://stackoverflow.com/questions/28546572/how-to-find-duplicates-in-array-of-strings-in-d
I can't understand, why uniq work for array of int but do not
work with array of strings.
int[] arr = [ 1,
Docs will get a lot better in the next release:
http://dlang.org/phobos-prerelease/std_algorithm_iteration.html#uniq
Iterates unique - _consecutive_ - elements of the given range
Could you explain what does it's mean? I do not understand what
is _consecutive_ mean in this content... and why it's not work
with strings...
https://issues.dlang.org/show_bug.cgi?id=14186
--- Comment #6 from ag0ae...@gmail.com ---
(In reply to Sobirari Muhomori from comment #5)
Looks like gcc has some history under this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6905
That ticket is about C++ though. But if C99
On Mon, Feb 16, 2015 at 09:36:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
One thought about forward and SortOutput - first may e.g. go in
std.functional and the latter belongs to sorting.
On 2/16/15 12:23 PM, Jacob Carlborg wrote:
On 2015-02-16 17:51, Gary Willoughby wrote:
I agree.
To be brutally honest the biggest release mistakes (which seems to be
getting worse lately) are D releases with outstanding regressions.
That's pretty unacceptable IMHO.
Yes, and that someone
I'm trying to figure out how to implement a light-weight wrappr
realizing type-safe indexing á lá Ada. Here's my first try:
struct Ix(T = size_t)
{
@safe pure: @nogc nothrow:
this(T ix) { this._ix = ix; }
alias _ix this;
private T _ix = 0;
}
struct IndexedBy(R, I)
{
auto
On Monday, 16 February 2015 at 20:09:09 UTC, Nordlöw wrote:
How can I prevent
jx[0] = 11;
from compiling?
Remove that `alias _r this;`. You don't want to forward opIndex,
so you can't use alias this which forwards everything that
doesn't compile. opDispatch may be an option to forward
On 2015-02-16 17:51, Gary Willoughby wrote:
I agree.
To be brutally honest the biggest release mistakes (which seems to be
getting worse lately) are D releases with outstanding regressions.
That's pretty unacceptable IMHO.
Yes, and that someone thinks we need release on a specific date, even
On Monday, 16 February 2015 at 20:48:29 UTC, Nordlöw wrote:
Thanks!
See also:
http://forum.dlang.org/thread/akibggljgcmmacsba...@forum.dlang.org
On Monday, 16 February 2015 at 20:31:22 UTC, Andrei Alexandrescu
wrote:
Martin, as our release czar you may want to publish the planned
ship date. -- Andrei
Isn't it already published?
http://dlang.org/changelog.html
On 2/16/15 11:46 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Feb 16, 2015 at 09:36:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
One thought about forward and SortOutput - first may e.g. go in
std.functional and the
On Monday, 16 February 2015 at 20:17:55 UTC, anonymous wrote:
Remove that `alias _r this;`. You don't want to forward
opIndex, so you can't use alias this which forwards everything
that doesn't compile. opDispatch may be an option to forward
everything but opIndex.
Thanks!
On 2/16/15 5:10 AM, Daniel Murphy wrote:
Marc Schütz wrote in message
news:iftpzvhoyxxqhbfsx...@forum.dlang.org...
To be really consistent,
x in arr
would need to be equivalent to:
(x = 0) (x arr.length)
`in` tests for the presence of a _key_ in AAs, and the equivalent
notion of
On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:
Range violation is an Error, but never mind that. The real
question is: given all the work related to @nogc, wouldn't it
be better for such common Errors to be preallocated and only
have file and line updated when they are thrown?
@nogc
On Monday, 16 February 2015 at 20:17:55 UTC, anonymous wrote:
that doesn't compile. opDispatch may be an option to forward
everything but opIndex.
What about disable?
On Sunday, 15 February 2015 at 04:24:12 UTC, Craig Dillabaugh
wrote:
On Saturday, 14 February 2015 at 06:56:00 UTC, Russel Winder
wrote:
Craig,
I have signed up on Melange as a potential mentor, user name
russel_winder.
Thank you.
Russel,
I haven't yet heard from Martin on his Melange
On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
Most likely due to that the support for dynamic libraries is fairly new only
works on Linux (?).
Part of the test suite creates a DLL using D for Windows.
Exciting news, my book on CTFE is out[0].
To summarize, it contains most of my knowledge of CTFE in a generic'ish
form with examples being in D.
There is a bit of talk of what support there can be and what we have.
The design patterns are probably the most interesting.
If you have any
On Monday, 16 February 2015 at 21:41:00 UTC, Walter Bright wrote:
On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
Most likely due to that the support for dynamic libraries is
fairly new only
works on Linux (?).
Part of the test suite creates a DLL using D for Windows.
Martin recently added
On Monday, 16 February 2015 at 06:21:22 UTC, H. S. Teoh wrote:
On Sun, Feb 15, 2015 at 04:02:30PM -0800, Andrei Alexandrescu
via Digitalmars-d wrote:
[...]
* We have the fastest compiler _and_ language in the world,
yet it's
impossible to unittest one module; unittesting one requires
building
On Monday, 16 February 2015 at 19:52:20 UTC, Dennis Ritchie wrote:
Hi.
And how to read Data from the input stream?
import std.stdio;
import std.bigint;
void main() {
BigInt n;
readf( %?, n);
writeln(n);
}
The readf function does not seem to support reading BigInts
On Tuesday, 17 February 2015 at 05:52:23 UTC, philippecp wrote:
I was wondering the same myself. I think there would be a lot
of negative side effects to using alternate memory model other
than GC (non-gc could introduce leaks, on stack has potential
to be overwritten). For that reason, I
On Monday, 16 February 2015 at 23:17:03 UTC, Jonathan Marler
wrote:
Is there a proposal for how D will support throwing Exceptions
in @nogc code in the future? I've searched the forums and
found different proposals that involve things like
pre-allocated exceptions, non-gc heap allocated
On Tuesday, 17 February 2015 at 07:28:03 UTC, weaselcat wrote:
Would RefCounted!T being @nogc help alleviate this issue?
I've heard of RefCounted and I understand the concept but I've
never used it. I'll do some reading a some experiments. Maybe
this will work :)
Benjamin Thaut wrote in message news:mbuok2$pn5$1...@digitalmars.com...
Error: ICE: Unsupported type void()
So close...
Good news is that that's a compiler bug and not a language limitation.
Although allowing you to pass a function type to a template in the first
place might also be a
On Tuesday, 17 February 2015 at 02:16:58 UTC, Kelly wrote:
P.S. I HATE THIS FORUM EDITORplease add a preview button,
whoever takes care of this!?!? I take notes in a different
editor and then paste here and it looks fine, only to end up
mangled when actually submitted...ugh :)
You
I'm looking to manage my current project with dub, but there is
one problem that has been getting in my way. I want to use
`-rpath=$ORIGIN`, which I can pass with `-L-rpath=\$ORIGIN` when
directly invoking the compiler, but when putting `-rpath=$ORIGIN`
or `-rpath=\$ORIGIN` in lflags, dub
On Monday, 16 February 2015 at 07:14:35 UTC, Andrei Alexandrescu
wrote:
Oh, could you please add that DConf has a call for submissions
and an early bird discount through Feb 28?
it was already there - DConf 2015 is right under the stats and I
keep that little section updated with the latest.
https://issues.dlang.org/show_bug.cgi?id=12500
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|andrej.mitrov...@gmail.com |
--
On 2015-02-16 at 22:12, Jonathan Marler wrote:
On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:
Range violation is an Error, but never mind that. The real question is: given
all the work related to @nogc, wouldn't it be better for such common Errors to
be preallocated and only have file
Benjamin Thaut wrote in message news:mbtena$2n46$1...@digitalmars.com...
I understand that void function() is actually a function pointer and
thus the mangling is correct. But in what way would you actually able
to mirror the C++ declaration of ezDelegate? Does it even work? This
would be a
Hi Kelly,
It's done, I've merged latest LDC upstream + your build fixes
into Calypso.
About Microsoft vtables they work much more differently from the
Itanium ones than I thought, it's going to a lot trickier than
just a few lines of code so I won't be able to make D classes
inheriting
dbeaengine[1] is a simple BeaEngine[2] interface for the D
programming language. The BeaEngine is an X86 and X86_64 library
which can be used to disassemble X86 and X86_64 byte-code.
The programming interface is simple and outrageously easy to use
(a single function named `disassemble()` ).
Is there a proposal for how D will support throwing Exceptions in
@nogc code in the future? I've searched the forums and found
different proposals that involve things like pre-allocated
exceptions, non-gc heap allocated exceptions or even stack
allocated exceptions. I don't want to debate
https://issues.dlang.org/show_bug.cgi?id=13834
--- Comment #1 from Martin Nowak c...@dawg.eu ---
Implementing the more space efficient variant of the algorithm when the final
path isn't needed is another optimization.
On Monday, 16 February 2015 at 07:05:41 UTC, Meta wrote:
Should be A module?
yes, thanks!
https://issues.dlang.org/show_bug.cgi?id=4764
Nick Treleaven ntrel-...@mybtinternet.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Marc Schütz wrote in message
news:iftpzvhoyxxqhbfsx...@forum.dlang.org...
To be really consistent,
x in arr
would need to be equivalent to:
(x = 0) (x arr.length)
`in` tests for the presence of a _key_ in AAs, and the equivalent notion
of a key for arrays is an index.
It's
On Monday, 16 February 2015 at 13:10:44 UTC, Daniel Murphy wrote:
Marc Schütz wrote in message
news:iftpzvhoyxxqhbfsx...@forum.dlang.org...
To be really consistent,
x in arr
would need to be equivalent to:
(x = 0) (x arr.length)
`in` tests for the presence of a _key_ in AAs, and
On Monday, 16 February 2015 at 03:49:14 UTC, Andrei Alexandrescu
wrote:
It has two seemingly random names in it: forward and
SortOutput. Also the table at the beginning uses some odd
small fonts for the function names.
About the font issue:
On Tuesday, 17 February 2015 at 01:53:22 UTC, Elie Morisse wrote:
Hi Kelly,
It's done, I've merged latest LDC upstream + your build fixes
into Calypso.
Alright, cool. I pulled it here and things build fine on Linux.
Showcase and string examples work nicely.
About Microsoft vtables they
On 2/16/2015 3:07 PM, Rikki Cattermole wrote:
[0] https://leanpub.com/ctfe
Thank you. I bought my copy!
On Monday, 16 February 2015 at 11:57:36 UTC, FG wrote:
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be
applauded for introducing what may become the biggest source of
typos. :)
Adjoining would
We've got arbitrary precision integers, why not arbitrary
precision floating point?
Something recently broke in the dlang.org repo; now multi-word headings
are not properly rendered in HTML. See, for example:
http://dlang.org/phobos-prerelease/std_string#.translate
The heading SeeAlso appears as a single word, whereas it should be two
words See Also. This doesn't appear
On Mon, Feb 16, 2015 at 07:51:16PM -0800, H. S. Teoh via Digitalmars-d wrote:
Something recently broke in the dlang.org repo; now multi-word headings
are not properly rendered in HTML. See, for example:
http://dlang.org/phobos-prerelease/std_string#.translate
The heading SeeAlso
https://issues.dlang.org/show_bug.cgi?id=13920
bb.t...@gmx.com changed:
What|Removed |Added
Assignee|nob...@puremagic.com|k.hara...@gmail.com
--
On Tue, Feb 17, 2015 at 02:16:57 +, Kelly via Digitalmars-d-announce wrote:
P.S. I HATE THIS FORUM EDITORplease add a preview button,
whoever takes care of this!?!? I take notes in a different editor
and then paste here and it looks fine, only to end up mangled
when actually
https://issues.dlang.org/show_bug.cgi?id=14191
Issue ID: 14191
Summary: Failure to locate overload with template this
parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:
Yes, they would be in TLS. I know exceptions in general are a
complex problem, therefore I limited the comment only to
errors, because forbidding the use of `aa[key]` in @nogc seemed
odd (although I do think that `aa.get(key, default)`
On 17/02/2015 4:32 p.m., Walter Bright wrote:
On 2/16/2015 3:07 PM, Rikki Cattermole wrote:
[0] https://leanpub.com/ctfe
Thank you. I bought my copy!
No problem!
Just let me know any improvements that could be made. Updates are free
after all! (Leanpub is amazing, what with markdown
On Mon, Feb 16, 2015 at 08:20:10PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
Not sure how to fix this, as the anchor name probably shouldn't have
embedded spaces. :-(
[...]
Actually, this irritated me so much that I decided to hack-fix it:
https://issues.dlang.org/show_bug.cgi?id=13920
bb.t...@gmx.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
https://issues.dlang.org/show_bug.cgi?id=13949
bb.t...@gmx.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=14186
--- Comment #2 from Sobirari Muhomori dfj1es...@sneakemail.com ---
Interesting, C99 and C11 don't allow for that:
assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression
i.e. same precedence
Casper Færgemand wrote in message
news:aenkruurfmfanarke...@forum.dlang.org...
Java 7 changed its HashMap implementation to use TreeMap (red black search
tree) instead of LinkedList for its buckets, if the key can be sorted.
That puts the worst case lookup time from O(n) to O(log n) for
Hello Elie,
Ok, I tried to build on OS X with the LLVM/Clang revisions from
above and
the Calypso/LDC code from my github fork, but it is a no go.
Calypso compiles pretty easily, but there are issues with
vector not being
found, so then I install libc++ so that clang easily picks up the
On Sunday, 15 February 2015 at 21:23:13 UTC, Andrei Alexandrescu
wrote:
The one possible change would be to allow in with
statically-sized arrays, under the assumption that the amount
of data searched is fixed and proportional to the size of the
program.
To be really consistent,
x in arr
https://issues.dlang.org/show_bug.cgi?id=14186
--- Comment #3 from Sobirari Muhomori dfj1es...@sneakemail.com ---
Can you confirm it with --std=c99 -pedantic?
--
https://issues.dlang.org/show_bug.cgi?id=14186
--- Comment #4 from ag0ae...@gmail.com ---
(In reply to Sobirari Muhomori from comment #3)
Can you confirm it with --std=c99 -pedantic?
Same error:
$ gcc --std=c99 -pedantic test.c
test.c: In function ‘main’:
test.c:5:15: error: lvalue
https://issues.dlang.org/show_bug.cgi?id=14186
--- Comment #5 from Sobirari Muhomori dfj1es...@sneakemail.com ---
Looks like gcc has some history under this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6905
--
On Monday, 16 February 2015 at 11:57:36 UTC, FG wrote:
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be
applauded for introducing what may become the biggest source of
typos. :)
Adjoining would
https://issues.dlang.org/show_bug.cgi?id=9685
ag0ae...@gmail.com changed:
What|Removed |Added
Keywords||wrong-code
CC|
John Colvin:
I'm quite a fan of python's // operator for integer division,
especially when combined with python 3's choice to make /
always mean floating point division (i.e. 3/2 == float(3)/2,
3//2 == 1). It recognises that integer division is a weird
thing and separates it from the much
On Sunday, 15 February 2015 at 22:38:20 UTC, anonymous wrote:
And more:
import std.stdio;
struct MapResult(alias fun)
{
@property int front() {return fun();}
@property auto save() {return typeof(this)();}
}
void main()
{
int ys_length = 4;
auto dg = {return MapResult!({return
On 2/16/15 1:23 AM, Daniel Murphy wrote:
bearophile wrote in message news:jufdlgyynxiwbqubb...@forum.dlang.org...
D associative arrays used to be O(1) amortized and O(n ln n) in worst
case.
No, they were still O(n) worst case, for a single bucket with a
degenerate binary tree.
IIRC, the
I was wondering the same myself. I think there would be a lot of
negative side effects to using alternate memory model other than
GC (non-gc could introduce leaks, on stack has potential to be
overwritten). For that reason, I think the only choices that make
sense are that either @nogc
Am 17.02.2015 um 02:21 schrieb Daniel Murphy:
struct X(T) { pragma(msg, X.stringof); }
void main()
{
X!(typeof(*(void function()).init)) x;
}
Error: ICE: Unsupported type void()
So close...
https://issues.dlang.org/show_bug.cgi?id=7267
Mathias LANG pro.mathias.l...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
1 - 100 of 138 matches
Mail list logo
