On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote:
I know we don't place much value in TIOBE and it's brethren.
However, I thought that this was a milestone worthy of a note
anyways.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
I don't want to take your joy,
On Sunday, 27 April 2014 at 05:43:07 UTC, Andrei Alexandrescu
wrote:
Added SbrkRegion, SimpleBlocklist, and Blocklist.
http://erdani.com/d/phobos-prerelease/std_allocator.html#.SbrkRegion
http://erdani.com/d/phobos-prerelease/std_allocator.html#.SimpleBlocklist
Walter Bright wrote in message news:ljh472$2233$1...@digitalmars.com...
True. But what D doesn't have is a global namespace. I don't propose one
for D, but C++ symbols may appear in the C++ global namespace, or in a C++
namespace. So using D modules to represent C++ namespaces has a problem.
On 4/26/2014 11:22 PM, Daniel Murphy wrote:
I am NOT suggesting module name and namespace mangling should be tied together.
Use D modules for symbol organisation, and add a simple feature for specifying a
C++ namespace when required.
The 'namespace' feature actually does work analogously to
On Sunday, 27 April 2014 at 00:07:22 UTC, Adam D. Ruppe wrote:
On Sunday, 27 April 2014 at 00:01:21 UTC, Andrei Alexandrescu
wrote:
Oops. No bug. -- Andrei
Nah, sorry, that was my giant mistake, I didn't actually do the
math before saying check your math and let my brain get
confused into
Walter Bright wrote in message news:ljiadl$4uq$1...@digitalmars.com...
The 'namespace' feature actually does work analogously to modules.
And it shouldn't. We have modules that work like modules. We don't need
another.
On 4/27/2014 12:19 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:ljiadl$4uq$1...@digitalmars.com...
The 'namespace' feature actually does work analogously to modules.
And it shouldn't. We have modules that work like modules. We don't need
another.
I am not seeing an
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
Using named mixin templates for pure scope resolution is side
effect and should be discouraged in any reasonable code.
There's also the un-instantiable class trick:
-
final abstract class Scope
{
static:
}
-
A
On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote:
There's a need for scoping symbols other than in modules,
What is that need?
Not unless we have a really solid DIP.
What's wrong with the DIP?
Idealism aside, modules have some implementation issues right now
which force
Walter Bright newshou...@digitalmars.com wrote:
On 4/26/2014 12:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and organisation in D code -
modules!
True. But what D doesn't have is a global namespace. I don't propose one
for D, but C++ symbols may appear in the
Walter Bright wrote in message news:ljie28$7ei$1...@digitalmars.com...
I am not seeing an actual proposal. If I missed it, please point me at it.
You missed it. `pragma(cpp_namespace, ...)` and all enclosed C++
declarations are mangled accordingly. No other changes.
On 4/27/14, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote:
There's a need for scoping symbols other than in modules,
What is that need?
Here's some examples from Phobos:
std.uni.unicode is a lowercase-named
Walter Bright newshou...@digitalmars.com wrote:
On 4/26/2014 4:01 AM, Mike wrote:
pragma(cpp_namespace, A.B)
extern(C++) void f() {}
This implies that it only affects the name mangling. There needs to be a
scope created, too.
I think that's the crucial point here. Most people that disagree
27-Apr-2014 13:04, Andrej Mitrovic via Digitalmars-d пишет:
On 4/27/14, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote:
There's a need for scoping symbols other than in modules,
What is that need?
Here's some
On Sunday, 27 April 2014 at 00:21:19 UTC, Aleksandar Ruzicic
wrote:
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be
Here's another thing that should be allowed that doesn't depend
on optimizations:
Any code path in a @nogc function that is guaranteed to abort the
program should be exempt from @nogc enforcement. This includes
assert(0) and throwing an Error.
Take std.exception.assumeWontThrow() as an
I have a question regarding `owns`:
bool owns(void[] b);
The documentation states it should return true if b has been
allocated with this allocator. But what should happen if a
sub-slice of an allocated object is passed? Or when a slice is
passed that contains/overlaps an object
Also, there is an `expand()` method, but no `shrink()`. Is that
an oversight, or intentional?
On Sunday, 27 April 2014 at 11:13:42 UTC, Marc Schütz wrote:
Also, there is an `expand()` method, but no `shrink()`. Is that
an oversight, or intentional?
If I remember correctly, this was discussed in the initial review
of Andrei's proposal (just search the NG for std.allocator).
David
On Sunday, 27 April 2014 at 08:16:58 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Using named mixin templates for pure scope resolution is side
effect and should be discouraged in any reasonable code.
There's also the
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
I believe this is a temporary workaround. Once bugs and
deficiencies of existing module system will be taken care of,
there won't be any need in using namespace emulation.
That's not true. Remember that when you're
On 2014-04-26 16:43, Daniel Murphy wrote:
At least these days it only happens when Walter and Andrei agree instead
of just Walter merging whatever he feels like.
Yeah, but it's still a problem when the rest of the community disagrees.
--
/Jacob Carlborg
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
This pops up very often so I have just went and implemented proof
of concept for package(pkg1.pkg2.pkg3) protection attribute
syntax. Was relatively straightforward, will do a PR soon-ish
after some cleanup.
Yeah. It's
On Sunday, 27 April 2014 at 13:43:13 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I believe this is a temporary workaround. Once bugs and
deficiencies of existing module system will be taken care of,
there won't be any
On Sunday, 27 April 2014 at 13:49:15 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
This pops up very often so I have just went and implemented
proof
of concept for package(pkg1.pkg2.pkg3) protection attribute
syntax. Was
extern (C++, N.M) { void foo(); }
extern (C++) namespace N { namespace M { void foo(); }}
Excellent. Solves the problem, doesn't add new language elements.
On Sunday, 27 April 2014 at 13:10:42 UTC, David Nadlinger wrote:
On Sunday, 27 April 2014 at 11:13:42 UTC, Marc Schütz wrote:
Also, there is an `expand()` method, but no `shrink()`. Is
that an oversight, or intentional?
If I remember correctly, this was discussed in the initial
review of
On Sunday, 27 April 2014 at 06:13:22 UTC, Brian Schott wrot
T* allocate(T, Allocator, Args...)(auto ref Allocator a, auto
ref Args args)
@trusted if (is (T == struct))
{
Though, it's not trusted.
Andrei Alexandrescu:
Destruction is as always welcome. I plan to get into tracing
tomorrow morning.
How easy is to implement a OS-portable (disk-backed) virtual
memory scheme using std.allocator? :-) Is it a good idea to
include one such scheme in std.allocator?
Bye,
bearophile
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N {
On 4/26/14, 11:13 PM, Brian Schott wrote:
There are quite a few places where functions could be marked pure,
nothrow, @safe, or @trusted that have not been. I have a pull request
open for many of these.
Thanks!
I also have a feature request. I think something like this should be
added to
On 4/27/14, 4:13 AM, Marc Schütz schue...@gmx.net wrote:
Also, there is an `expand()` method, but no `shrink()`. Is that an
oversight, or intentional?
I tried to avoid it because it's error-prone. reallocate() should shrink
in place where appropriate. But I'll add it if it turns out it's
Jason King wrote in message news:cgcqomgrrtujzckvu...@forum.dlang.org...
extern (C++, N.M) { void foo(); }
extern (C++) namespace N { namespace M { void foo(); }}
Excellent. Solves the problem, doesn't add new language elements.
It adds a new scoping rule, and new syntax.
People, why you hates ctors for structs ?
Default ctor - simple a workaround.
Just allow ctors with structs and it's all.
On 4/27/14, 3:58 AM, Marc Schütz schue...@gmx.net wrote:
I have a question regarding `owns`:
bool owns(void[] b);
The documentation states it should return true if b has been allocated
with this allocator. But what should happen if a sub-slice of an
allocated object is passed? Or when a
On 4/27/14, 7:51 AM, bearophile wrote:
Andrei Alexandrescu:
Destruction is as always welcome. I plan to get into tracing tomorrow
morning.
How easy is to implement a OS-portable (disk-backed) virtual memory
scheme using std.allocator? :-) Is it a good idea to include one such
scheme in
Andrei Alexandrescu:
I just added MmapAllocator:
http://erdani.com/d/phobos-prerelease/std_allocator.html#.MmapAllocator
If anyone would like to add a Windows implementation, that
would be great.
So it's not using this portable module?
http://dlang.org/phobos/std_mmfile.html
Bye,
On 4/27/14, 9:21 AM, bearophile wrote:
Andrei Alexandrescu:
I just added MmapAllocator:
http://erdani.com/d/phobos-prerelease/std_allocator.html#.MmapAllocator
If anyone would like to add a Windows implementation, that would be
great.
So it's not using this portable module?
On 4/27/14, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
Hey, I am trying to be an optimist here for a minute! And you are
not helping ;)
You must be new around here! I've had plenty of pulls being stuck in
the tarpit and then rejected. :)
But actually, package(foo.bar) is
Hi all,
I am doing some updates to the C back end of my binding, and I
wanted to know what it would entail to be able to distribute
implib along with my CMake things. I was just thinking that it
would be nice to automatically produce .lib files when it builds
32bit libs on Windows systems.
Am Sun, 27 Apr 2014 00:08:17 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 4/26/2014 11:22 PM, Daniel Murphy wrote:
I am NOT suggesting module name and namespace mangling should be tied
together.
Use D modules for symbol organisation, and add a simple feature for
On 4/27/2014 2:08 AM, Dmitry Olshansky wrote:
Technically it's a functor that works like this:
auto ascii = unicode(ASCII);
Then opDispatch is just a nice bonus to go with it, and struct is the only shop
to offer such goodies.
So it's not just a namespace!
On 4/27/2014 2:04 AM, Andrej Mitrovic via Digitalmars-d wrote:
And here's std.datetime using a similar trick:
-
/++
Effectively a namespace to make it clear that the methods it contains are
getting the time from the system clock. It cannot be instantiated.
+/
final class Clock
On 4/27/2014 1:55 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:ljie28$7ei$1...@digitalmars.com...
I am not seeing an actual proposal. If I missed it, please point me at it.
You missed it. `pragma(cpp_namespace, ...)` and all enclosed C++ declarations
are mangled
http://wiki.dlang.org/DIP61
On Sunday, 27 April 2014 at 16:01:55 UTC, Andrei Alexandrescu
wrote:
I just added MmapAllocator:
http://erdani.com/d/phobos-prerelease/std_allocator.html#.MmapAllocator
If anyone would like to add a Windows implementation, that
would be great.
Andrei
This could come in handy
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Sounds awesome.
On Thursday, 10 April 2014 at 11:13:45 UTC, monarch_dodra wrote:
Or a named function: auto foo = foo();
Or a make template: auto foo = make!Foo();
Or a dummy argument: auto foo = Foo(Foo.dummy);
Or ditto with a global dummy: auto foo = Foo(dummyArg);
Or use a static opCall:auto foo =
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Without aliasing and with a unified scope operator you will get
name clashes between D and C++. You should address why this is
not an issue (e.g. practical and not tedious).
On 4/27/2014 1:44 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Without aliasing and with a unified scope operator you will get name clashes
between D and C++. You should address
On Sun, Apr 27, 2014 at 2:54 PM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
http://wiki.dlang.org/DIP61
What happens if you try to interface with two different C++ libraries that
use the same exact namespaces?
On 4/27/2014 1:53 PM, Jeremy DeHaan wrote:
According to the license [implib] comes with, I would need to obtain a
redistribution license for this. Anyone else had any experience with that?
Standard procedure is to just email Walter your request. There's a JS
Send email button here:
On 4/27/2014 3:07 PM, Caligo via Digitalmars-d wrote:
On Sun, Apr 27, 2014 at 2:54 PM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
http://wiki.dlang.org/DIP61
What happens if you try to interface with two different C++ libraries
Added a bunch more stuff:
* new optional primitives:
- empty() returns true if no current allocation
- zeroesAllocations is true if the allocator automatically sets freshly
allocated memory to zero
- resolveInternalPointer(p) gives the allocated block corresponding to p
* An interesting
Andrei Alexandrescu:
- zeroesAllocations is true if the allocator automatically sets
freshly allocated memory to zero
In some cases there is a need for a certain zeroing, even when
memory is deallocated:
https://issues.dlang.org/show_bug.cgi?id=10661
This can be added.
In some case there
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
This is the new grammar?
LinkageAttribute:
'extern' '(' identifier '++'? (',' identifier)? ')'
On 4/27/2014 5:58 PM, Brian Schott wrote:
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
This is the new grammar?
LinkageAttribute:
'extern' '(' identifier '++'? (',' identifier)? ')'
You can also have N.M
On Sunday, 27 April 2014 at 20:53:31 UTC, Walter Bright wrote:
Example of what you mean, please.
If the c++ library is std:: and then later either D or C++ is
expanded with a name clash, and the externs are auto generated,
e.g. std.something appears on both sides, what happens then
when you
On Sunday, 27 April 2014 at 17:53:18 UTC, Jeremy DeHaan wrote:
Hi all,
I am doing some updates to the C back end of my binding, and I
wanted to know what it would entail to be able to distribute
implib along with my CMake things. I was just thinking that it
would be nice to automatically
On 4/27/14, Damian Day via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
So I have this procedure.
Have a look at std.exception.assumeWontThrow:
http://dlang.org/phobos/std_exception.html#.assumeWontThrow
Am 26.04.2014 20:18, schrieb Entry:
I'd like to use GLFW from Deimos, but I couldn't get it to work (DMD
said it cannot use libglfw.a) and I've read somewhere that only GDC can
use these DLLs directly (with a D header, but that's still better than
hooking the methods). So do I need GDC for
On Sunday, 27 April 2014 at 02:06:14 UTC, Ali Çehreli wrote:
I don't know whether the inconsistency is a bug but according
to documentation, static this inside a module are executed in
lexical order: Static constructors within a module are
executed in the lexical order in which they appear.
spec:
Although, yeah, it would be nice if the compiler emitted some
kind of warning pointing this (if it's at all possible). What
got me confused was indeed the disparity of results from
changing small things.
If you think this can be done and it's useful, then ask for this
enhancement
Lazy arguments in general allocate, but who is to blame for the
allocation?
Isn't the allocation at the calling point?
This code:
void foo(lazy int x) @nogc {
auto r = x(); // Error
}
void main() {
foo(1);
}
Gives:
test.d(2,15): Error: @nogc function 'test.foo' cannot call
On Sunday, 27 April 2014 at 13:09:39 UTC, bearophile wrote:
Lazy arguments in general allocate, but who is to blame for the
allocation?
Isn't the allocation at the calling point?
This code:
void foo(lazy int x) @nogc {
auto r = x(); // Error
}
void main() {
foo(1);
}
Gives:
spec:
Although, yeah, it would be nice if the compiler emitted some
kind of warning pointing this (if it's at all possible). What
got me confused was indeed the disparity of results from
changing small things.
D doesn't like warnings, but it could be an error. This is
minimized code:
Dicebot:
It happens because attribute inference does not work properly
on generated delegated for lazy argument. I think it is a bug
lazy int x is effectively same as int delegate() x and
@nogc states that you can only call other @nogc functions and
delegates from something annotated as
On Sunday, 27 April 2014 at 13:31:39 UTC, bearophile wrote:
Is it possible and a good idea to raise a compilation error in
such cases where code tries to use Bar static fields before bar
static this() has run? (But perhaps a more fine-grained error
is needed, that tracks single fields, to
On Sunday, 27 April 2014 at 08:04:54 UTC, Andrej Mitrovic via
Digitalmars-d-learn wrote:
On 4/27/14, Damian Day via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
So I have this procedure.
Have a look at std.exception.assumeWontThrow:
spec:
I usually try to refrain myself from opinionating on stuff
where i lack proper knowledge and i'am still a newbie with D
(contrary to you bearophile).
It's not just a matter of experience, when there are many
interacting parts it's also a matter of intelligence (and people
like Timon
I'm trying to create a basic List type using Algebraic, but the
compiler keeps complaining about recursive aliasing.
import std.variant;
struct Cons(T, U: List)
{
public static opCall(T t, U u)
{
}
}
//Error
alias List = Algebraic!(typeof(null), Cons!(int, This));
Meta:
I'm trying to create a basic List type using Algebraic, but the
compiler keeps complaining about recursive aliasing.
As stated in its docs, Algebraic is not yet finished and good for
recursive data structures. But here I have put an usage example
of that kind:
Meta:
alias List = Algebraic!(typeof(null), Cons!(int, This));
Also your Cons seems a value type, like Algebraic itself. You
have to avoid creating an infinite-size algebraic value.
Bye,
bearophile
On Sunday, 27 April 2014 at 20:22:12 UTC, bearophile wrote:
Meta:
I'm trying to create a basic List type using Algebraic, but
the compiler keeps complaining about recursive aliasing.
As stated in its docs, Algebraic is not yet finished and good
for recursive data structures. But here I have
On Sunday, 27 April 2014 at 20:38:37 UTC, Meta wrote:
Is it necessary to use This[]? I tried changing it to This* and
it blew up on me.
I should specify. This did not work:
alias T = Algebraic!(int, This*);
void main() {
auto l = T(1, new T(2, new T(3, null)));
}
On Sunday, 27 April 2014 at 20:28:28 UTC, bearophile wrote:
Meta:
alias List = Algebraic!(typeof(null), Cons!(int, This));
Also your Cons seems a value type, like Algebraic itself. You
have to avoid creating an infinite-size algebraic value.
Bye,
bearophile
Yes, it's hard to figure out
Meta:
I should specify. This did not work:
alias T = Algebraic!(int, This*);
void main() {
auto l = T(1, new T(2, new T(3, null)));
}
An Algebraic is a sum type, so you can't store two value in it,
only one, an int or a T*. But this is not going to solve your
problems...
Bye,
On Sunday, 27 April 2014 at 20:54:02 UTC, bearophile wrote:
An Algebraic is a sum type, so you can't store two value in it,
only one, an int or a T*. But this is not going to solve your
problems...
Bye,
bearophile
Ah, you're right. I'm getting mixed up from my own initial
example. Fiddling
Meta:
The more I try to use Algebraic, the more I come to think that
this is something that can't be done cleanly in a library, even
in D.
Algebraic is currently unfinished and needs improvements. If it
turns out it's not possible to implement it well in library code,
we can find the
If no one comment I'll put this in Bugzilla.
https://issues.dlang.org/show_bug.cgi?id=12667
Bye,
bearophile
i wrote a module which public imports other modules (to avoid
importing 'em by hand, 'cause import lists depends on version()).
then i imported this 'main' module with renaming: import zmod =
my.module;
now i can't acces any identifiers from modules that my.module
public imports and i forced
I would like to do something like this:
Foo[Bar][Baz] nestedAA;
auto innerAA = nestedAA[someBaz];
innerAA[someBar] = someFoo;
assert(someFoo in nestedAA[someBaz]);
Unfortunately, this does not do what I would like, because innerAA
appears to be a copy rather than a reference. Is there a nice
On Sunday, 27 April 2014 at 00:48:53 UTC, Ali Çehreli wrote:
I think the following is a start:
import std.variant;
class MyClass
{
Variant[string] store;
void attach(T)(string key, ref T var)
{
store[key] = var;
}
void set(T)(string key, T value)
{
I am trying to figure out how to change the value of an element
in a BinaryHeap (from std.container) and have it repositioned
such that the heap is still valid.
Can anyone help me with this? The approach I would have taken (I
think) is to remove the elements that get new values from the
fOn 04/27/2014 06:00 PM, David Held wrote:
I would like to do something like this:
Foo[Bar][Baz] nestedAA;
auto innerAA = nestedAA[someBaz];
innerAA[someBar] = someFoo;
assert(someFoo in nestedAA[someBaz]);
in operator uses a key, not a value. This should work:
assert(someBar in
https://issues.dlang.org/show_bug.cgi?id=12661
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
However it might also be related to:
https://issues.dlang.org/show_bug.cgi?id=12657
--
https://issues.dlang.org/show_bug.cgi?id=12661
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=12661
Dmitry Olshansky dmitry.o...@gmail.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=3827
--- Comment #32 from bearophile_h...@eml.cc ---
A new bug of mine caused by the implicit concatenation of strings. The point of
this little program is to show the Phobos isNumeric function:
void main() {
import std.stdio, std.string, std.array;
https://issues.dlang.org/show_bug.cgi?id=12644
--- Comment #1 from bearophile_h...@eml.cc ---
Also:
void main() @nogc {
import std.math: log, acos;
auto x1 = log(2.2);
auto x2 = acos(0.0);
}
--
https://issues.dlang.org/show_bug.cgi?id=12228
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Keywords||pull
https://issues.dlang.org/show_bug.cgi?id=9535
--- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
Looks like I missed the deadline, was busy with other pulls.
--
https://issues.dlang.org/show_bug.cgi?id=12662
Issue ID: 12662
Summary: std.range.retro is not @nogc
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: rejects-valid
Severity:
https://issues.dlang.org/show_bug.cgi?id=1371
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=1870
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=12632
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=12096
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=12093
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
*** Issue 12632 has been marked as a duplicate of this issue. ***
--
https://issues.dlang.org/show_bug.cgi?id=10661
David Nadlinger c...@klickverbot.at changed:
What|Removed |Added
CC||c...@klickverbot.at
https://issues.dlang.org/show_bug.cgi?id=12663
Issue ID: 12663
Summary: Wrong error message for mutation of immutable static
array
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
1 - 100 of 140 matches
Mail list logo
