Re: D Breaks on to the TIOBE Top 20 List.
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, but tiobe has its mood swings: Groovy was within the top 20 last year, see http://glaforge.appspot.com/article/groovy-enters-top-20-of-the-tiobe-language-index Now it is somewhere below the top 40. I think it was below the top 50 at the beginning of the year. Nevertheless, it is certainly good news :-).
Re: FYI - mo' work on std.allocator
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
http://erdani.com/d/phobos-prerelease/std_allocator.html#.Blocklist
https://github.com/andralex/phobos/blob/allocator/std/allocator.d
Destruction is as always welcome. I plan to get into tracing
tomorrow morning.
Andrei
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.
I also have a feature request. I think something like this should
be added to std.allocator:
/**
* Shortcut that encapsulates a cast and a call to emplace()
* Params:
* a = the allocator to use
* args = the arguments to $(D T)'s constructor
* Returns: a pointer to an instance of $(D T).
*/
T* allocate(T, Allocator, Args...)(auto ref Allocator a, auto ref
Args args)
@trusted if (is (T == struct))
{
import std.conv : emplace;
void[] mem = a.allocate(T.sizeof);
return emplace(cast(T*) mem.ptr, args);
}
The allocate-cast-initialize pattern is incredibly common in the
code that I've written using allocators so far and I'd like it to
be in Phobos so that it does not need to be re-implemented
everywhere.
Re: DIP61: Add namespaces to D
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. I think you've misunderstood me. Modules should be used for the same exact thing they currently are - organising symbols. If you want function 'foo' to be inside module 'bar' you put 'foo' inside 'bar'. Once you have the symbol layout you want, you then annotate the declarations to specify which C++ namespace they are inside, so the mangling matches. 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.
Re: DIP61: Add namespaces to D
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 modules.
Re: possible bug in std.conv.parse
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 thinking 1000 was 128, but it is actually -128 in twos complement, the high bit is set so it is negative. Yeah, or just remember that signed representation are evenly split between negatives and positives, but positives get the '0': Positives: [0 .. high); Negatives: [-high .. 0); It's an interesting source of bugs, and the reason you should never store an absolute value in a singed object. Since -int.min is still int.min.
Re: DIP61: Add namespaces to D
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.
Re: DIP61: Add namespaces to D
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 actual proposal. If I missed it, please point me at it.
Re: DIP61: Add namespaces to D
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 struct-based version is also possible. It's used in Phobos and other
libraries. There's a need for scoping symbols other than in modules,
but I'm not a fan of pushing C++ features in D. Not unless we have a
really solid DIP.
Idealism aside, modules have some implementation issues right now
which force people to use workarounds like named mixins or the above
trick, e.g. package access not being propagated up/down a hierarchy.
Re: DIP61: Add namespaces to D
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 people to use workarounds like named mixins or the above trick, e.g. package access not being propagated up/down a hierarchy. ??
Re: DIP61: Add namespaces to D
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 C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem. But C++ namespaces and D modules don't have to match at all. You can import any C++ function from an arbitrary namespace into any D module, just as you like. Also, I guess there is a reason, why D doesn't have a global module. Tobi
Re: DIP61: Add namespaces to D
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.
Re: DIP61: Add namespaces to 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 examples from Phobos: std.uni.unicode is a lowercase-named struct because it's supposed to be used as a namespace: - auto ascii = unicode.ASCII; - 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 - I've seen other libraries use this sort of trick. E.g. the D1 Harmonia GUI library, but I'm pretty sure I saw it in some D2 libraries. Not unless we have a really solid DIP. What's wrong with the DIP? It's barely 10 sentences long, I've seen forum posts longer than this. It's supposed to be solid, with lots of example code, and also any drawbacks or potential conflicts being listed (you list none at all). It doesn't have a FAQ, links to other competing proposals, etc. And arbitrary decisions are listed in that DIP without any rationale whatsoever, e.g.: - Unlike C++, namespaces in D will be 'closed' meaning that new declarations cannot be inserted into a namespace after the closing } = rationale? - C++ Argument Dependent Lookup (aka Koenig Lookup) will not be supported. = rationale? There are other well-written DIPs in there for reference. Idealism aside, modules have some implementation issues right now which force people to use workarounds like named mixins or the above trick, e.g. package access not being propagated up/down a hierarchy. ?? Here's the report: https://issues.dlang.org/show_bug.cgi?id=2529 Don's conclusion is what I agree with: https://issues.dlang.org/show_bug.cgi?id=2529#c1 Quote: the existing 'package' semantics force you to a flat hierarchy. Also, package access can be worked around in user-code: https://issues.dlang.org/show_bug.cgi?id=9381
Re: DIP61: Add namespaces to D
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 with your
proposal disagree exactly with that.
Scope should be created by modules and only modules.
Tobi
Re: DIP61: Add namespaces to D
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 examples from Phobos: std.uni.unicode is a lowercase-named struct because it's supposed to be used as a namespace: - auto ascii = unicode.ASCII; - 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. -- Dmitry Olshansky
Re: DIP61: Add namespaces to D
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 semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Or maybe reuse existing keywords:
extern (C++) scope N.M { void foo(); }
or
extern (C++) module interface N.M { void foo(); }
or something along those lines.. but maybe it should look a bit
ugly :)
extern (C++)!(N.M) { void foo(); }
;)
Re: DIP60: @nogc attribute
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 example:
T assumeWontThrow(T)(lazy T expr,
string msg = null,
string file = __FILE__,
size_t line = __LINE__) nothrow
{
try
{
return expr;
}
catch(Exception e)
{
immutable tail = msg.empty ? . : : ~ msg;
throw new AssertError(assumeWontThrow failed: Expression
did throw ~
tail, file, line);
}
}
Currently, this cannot be @nogc, because it uses `new` and `~`.
However, this only happens in preparation to throwing the
AssertError, which in turn causes the program to abort. I guess
in this situation, it's ok to allocate on the GC heap.
With my proposed rule, assumeWontThrow can be deduced to be @nogc
iff expr is @nogc. This allows more functions to be @nogc.
Re: FYI - mo' work on std.allocator
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 belonging to the allocator?
Re: FYI - mo' work on std.allocator
Also, there is an `expand()` method, but no `shrink()`. Is that an oversight, or intentional?
Re: FYI - mo' work on std.allocator
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
Re: DIP61: Add namespaces to D
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 un-instantiable class trick:
-
final abstract class Scope
{
static:
}
-
A struct-based version is also possible. It's used in Phobos
and other
libraries. There's a need for scoping symbols other than in
modules,
but I'm not a fan of pushing C++ features in D. Not unless we
have a
really solid DIP.
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.
Idealism aside, modules have some implementation issues right
now
which force people to use workarounds like named mixins or the
above
trick, e.g. package access not being propagated up/down a
hierarchy.
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.
Re: DIP61: Add namespaces to D
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 importing into a module you're import all symbols from that module into the current namespace. With symbols in aggregates you're forced to qualify the symbol with the name of the scope it's located in. One exception is the with() statement, but that can only be used in limited contexts (and is buggy as hell anyway).
Re: DIP60: @nogc attribute
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
Re: DIP61: Add namespaces to D
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 not so difficult to implement this stuff, the problem is agreeing to something (and getting a green light from WA).
Re: DIP61: Add namespaces to D
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 need in using namespace emulation. That's not true. Remember that when you're importing into a module you're import all symbols from that module into the current namespace. With symbols in aggregates you're forced to qualify the symbol with the name of the scope it's located in. One exception is the with() statement, but that can only be used in limited contexts (and is buggy as hell anyway). This is why fixing selective / renamed imports is so important. Once those are polished I'd consider using plain import anywhere but in quick scripts to be a bad style.
Re: DIP61: Add namespaces to D
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 relatively straightforward, will do a PR soon-ish after some cleanup. Yeah. It's not so difficult to implement this stuff, the problem is agreeing to something (and getting a green light from WA). Hey, I am trying to be an optimist here for a minute! And you are not helping ;)
Re: DIP61: Add namespaces to D
extern (C++, N.M) { void foo(); }
extern (C++) namespace N { namespace M { void foo(); }}
Excellent. Solves the problem, doesn't add new language elements.
Re: FYI - mo' work on std.allocator
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 Andrei's proposal (just search the NG for std.allocator). David Thanks, found it. The argument was that shrink can not be @safe [1], but Andrei wasn't opposed to adding it if desired [2]. [1] http://forum.dlang.org/thread/l1nvn4$ca3$1...@digitalmars.com?page=1 [2] http://forum.dlang.org/post/l1st99$10ug$1...@digitalmars.com
Re: FYI - mo' work on std.allocator
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.
Re: FYI - mo' work on std.allocator
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
Re: DIP61: Add namespaces to D
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 { namespace M { void foo(); }}
LGTM.
Re: FYI - mo' work on std.allocator
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 std.allocator:
/**
* Shortcut that encapsulates a cast and a call to emplace()
* Params:
* a = the allocator to use
* args = the arguments to $(D T)'s constructor
* Returns: a pointer to an instance of $(D T).
*/
T* allocate(T, Allocator, Args...)(auto ref Allocator a, auto ref Args
args)
@trusted if (is (T == struct))
{
import std.conv : emplace;
void[] mem = a.allocate(T.sizeof);
return emplace(cast(T*) mem.ptr, args);
}
The allocate-cast-initialize pattern is incredibly common in the code
that I've written using allocators so far and I'd like it to be in
Phobos so that it does not need to be re-implemented everywhere.
Totally. That will be part of typed allocators, module that's now empty :o).
Andrei
Re: FYI - mo' work on std.allocator
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 necessary. Andrei
Re: DIP61: Add namespaces to D
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. Neither of those things are
necessary.
Re: Explicit default constructor for structs
People, why you hates ctors for structs ? Default ctor - simple a workaround. Just allow ctors with structs and it's all.
Re: FYI - mo' work on std.allocator
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 slice is passed that contains/overlaps an object belonging to the allocator? Behavior is dependent on the allocator. Only full blocks (returned by allocate()) are guaranteed. -- Andrei
Re: FYI - mo' work on std.allocator
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 std.allocator? Bye, bearophile 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
Re: FYI - mo' work on std.allocator
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, bearophile
Re: FYI - mo' work on std.allocator
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? http://dlang.org/phobos/std_mmfile.html That's a class, so it would need its own allocation etc. Too much trouble. -- Andrei
Re: DIP61: Add namespaces to D
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 something I've seen mentioned before in some bug report. Or maybe we just had the same idea at some point. Good luck! :P
Distributing implib?
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. According to the license it comes with, I would need to obtain a redistribution license for this. Anyone else had any experience with that? Thanks much! Jeremy
Re: DIP61: Add namespaces to D
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 specifying a C++ namespace when required. The 'namespace' feature actually does work analogously to modules. Does that mean the full name in D would become something like this?: [D module ] [C++ namespace] company.project.company.project.func -- Marco
Re: DIP61: Add namespaces to D
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!
Re: DIP61: Add namespaces to D
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 - When you find yourself doing things like that, seriously consider creating a new module to do it, called clock. std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way.
Re: DIP61: Add namespaces to D
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 accordingly. No other changes. Ok, I saw that, and replied to it earlier this thread.
DIP61: redone to do extern(C++,N) syntax
http://wiki.dlang.org/DIP61
Re: FYI - mo' work on std.allocator
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 https://code.google.com/p/mman-win32/source/browse/#svn%2Ftrunk Guillaume
Re: DIP61: redone to do extern(C++,N) syntax
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 Sounds awesome.
Re: Explicit default constructor for structs
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 = Foo(); Or use an initialize function: Foo foo; foo.initialize(); And they are all broken in their own ways.
Re: DIP61: redone to do extern(C++,N) syntax
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).
Re: DIP61: redone to do extern(C++,N) syntax
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 why this is not an issue (e.g. practical and not tedious). Example of what you mean, please.
Re: DIP61: redone to do extern(C++,N) syntax
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?
Re: Distributing implib?
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: http://walterbright.com/
Re: DIP61: redone to do extern(C++,N) syntax
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 that use the same exact namespaces? If any of the names mangle to the same string, you'll get errors from the linker, just as you would if referencing those libraries from C++.
Re: FYI - mo' work on std.allocator
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 internal type EmbeddedTree: a binary search tree that can be threaded within memory blocks making them more searchable. * A type WithInternalPointers that uses an EmbeddedTree to implement resolveInternalPointer. * Default implementation of alignedReallocate. * Improved the sbrk-based region. https://github.com/andralex/phobos/blob/allocator/std/allocator.d The name WithInternalPointers is rather goofy - ideas? http://erdani.com/d/phobos-prerelease/std_allocator.html#.WithInternalPointers Andrei
Re: FYI - mo' work on std.allocator
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 is also a need to track and tell apart tainted/untainted memory zones. The name WithInternalPointers is rather goofy - ideas? Inner? Bye, bearophile
Re: DIP61: redone to do extern(C++,N) syntax
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)? ')'
Re: DIP61: redone to do extern(C++,N) syntax
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
Re: DIP61: redone to do extern(C++,N) syntax
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 recompile you app?
Re: Distributing implib?
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 produce .lib files when it builds 32bit libs on Windows systems. According to the license it comes with, I would need to obtain a redistribution license for this. Anyone else had any experience with that? Thanks much! Jeremy Nick already answered your question, but I have another suggestion for you. Set things up to look for implib (or perhaps coffimplib[1]), and complain if CMake can't find it. This tool should be part of the user's tools and environment, not part of your project. This may be my Linux bias talking, but I would tend to not want to ship binaries as part of my source. The good thing about CMake is that it can help you deal with your dependencies in a sane way. - Trent [1]ftp://ftp.digitalmars.com/coffimplib.zip
Re: Can I circumvent nothrow?
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
Re: DMD Deimos || GDC Deimos?
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 that or not? And would you actually recommend it? On a side note, getting GDC to work is a bitch. I had to copy around several DLLs (like libiconv-2.dll) and it's now working only with the libgcc_s_sjlj-1.dll copied right next to my application's exe. What am I doing wrong? This is really frustrating :/ I have a 10 month old glfw3.dll https://github.com/Dav1dde/BraLa/tree/master/lib/win Since glfw didnt change much (that was already at release), this is probably enough for you. Simply pass the glfw3.lib to the compiler and make sure glfw3.dll is reachable in runtime. But you can also build your own using cygwin (that's how I made it) and use implib for format conversion.
Re: Static constructors inconsistency
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. http://dlang.org/class.html#StaticConstructor So, if B depends on A then A's static this must appear before B's. Ali Arghh i hate when i make a mistake because i missed something on the docs, mainly when i actually read them. Thanks Ali. 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. Cheers,
Re: Static constructors inconsistency
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 request in Bugzilla. Bye, bearophile
@nogc and lazy arguments
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
non-@nogc delegate 'x'
Is it right to refuse the @nogc annotation on foo()? I think here
foo should be allowed to be @nogc, while the main() can't be
@nogc. What do you think?
Bye,
bearophile
Re: @nogc and lazy arguments
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:
test.d(2,15): Error: @nogc function 'test.foo' cannot call
non-@nogc delegate 'x'
Is it right to refuse the @nogc annotation on foo()? I think
here foo should be allowed to be @nogc, while the main() can't
be @nogc. What do you think?
Bye,
bearophile
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 @nogc.
Re: Static constructors inconsistency
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:
struct Foo {
static this() {
Bar b;
int x = b.data[0];
}
}
struct Bar {
static int[] data;
static this() {
data.length++;
}
}
void main() {}
A similar example:
struct Foo {
static this() {
Bar b;
int x = b.data[0];
}
}
struct Bar {
immutable static int[] data;
static this() {
data.length++;
}
}
void main() {}
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 allow more flexible code of
mutually initializing constructors).
Bye,
bearophile
Re: @nogc and lazy arguments
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 @nogc. https://issues.dlang.org/show_bug.cgi?id=12664 Bye, bearophile
Re: Static constructors inconsistency
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 allow more flexible code of mutually initializing constructors). Bye, bearophile 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). Having said this, the current behavior did confused me and it may very well confuse others in the future. I would very much prefer that an error had been thrown, because at that point, i would know immediately that it was me who was doing something wrong.. Cheers,
Re: Can I circumvent nothrow?
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:
http://dlang.org/phobos/std_exception.html#.assumeWontThrow
Keep in mind that assume won't throw will assert *should* an
exception actually be thrown.
If the function actually can and will throw, but you simply don't
care, you'd need a squelchException (which we don't have), or
more simply, just:
//
try {
myCode();
} catch (Exception){}
//
Re: Static constructors inconsistency
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 are more intelligent than me regardless my experience in D). If no one comment I'll put this in Bugzilla. Bye, bearophile
Creating a List Type Using std.variant.algebraic
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));
void main()
{
List l = Cons(1, Cons(2, Cons(3, null)));
}
I tried changing Cons like so:
struct Cons(T, U)
{
//...
}
Then I get:
Error: struct f809.Cons cannot deduce function from argument types
!()(int, typeof(null)), candidates are: f809.Cons(T, U)
Error: struct std.variant.This unknown size
Error: struct std.variant.This unknown size
Error: variable f809.Cons!(int, This).Cons.opCall.u no definition
of struct This
I'm not sure what else I could try. Does anyone have any advice
on using this?
Re: Creating a List Type Using std.variant.algebraic
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: http://rosettacode.org/wiki/Flatten_a_list#With_an_Algebraic_Data_Type Bye, bearophile
Re: Creating a List Type Using std.variant.algebraic
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
Re: Creating a List Type Using std.variant.algebraic
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 put an usage example of that kind: http://rosettacode.org/wiki/Flatten_a_list#With_an_Algebraic_Data_Type Bye, bearophile Is it necessary to use This[]? I tried changing it to This* and it blew up on me.
Re: Creating a List Type Using std.variant.algebraic
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)));
}
Re: Creating a List Type Using std.variant.algebraic
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 Algebraic's particular kind of magic.
Re: Creating a List Type Using std.variant.algebraic
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,
bearophile
Re: Creating a List Type Using std.variant.algebraic
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 with it a bit brings me back around to your
code:
import std.variant;
alias List = Algebraic!(int, This[]);
void main()
{
List l = List([List(1), List([List(2)])]);
}
Which is absolutely ugly. 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.
Re: Creating a List Type Using std.variant.algebraic
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 minimal core language additions needed to implement it well, and ask for them :) D is not set in stone regarding additive changes. Bye, bearophile
Re: Static constructors inconsistency
If no one comment I'll put this in Bugzilla. https://issues.dlang.org/show_bug.cgi?id=12667 Bye, bearophile
import with renaming and public import inside module
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 to copy-paste the whole my.module public import section each time. little sampe: module my.module; public import other.module; … module mainprogram; import my.module; now i can access other.module symbols without qualifiers and another case: module mainprogram; import zmod = my.module; now i CAN'T access other.module symbols without qualifiers. the only way to access 'em is to use horrible 'zmod.other.module.symbol', which completely defeats my purposes for public imports in my.module. can i use import renaming, but still access my.module public imports as if there was no renaming? i don't want to fall back to struct/class namespace emulation hackery and i don't want to prepend all names in my.module with some prefix (and my.module have many widely-used names such as 'init', 'deinit', 'write', etc). the question is: is such behaviour of 'import' intentional, or this is just bug and it will be fixed eventually?
'auto' with AA
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 way to tell 'auto' that I want a reference instead? Dave
Re: storing pointers in Variants
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)
{
*store[key].get!(T*) = value;
}
T get(T)(string key)
{
return *store[key].get!(T*)();
}
}
void main()
{
int sample = 42;
auto myObj = new MyClass;
myObj.attach(othername, sample);
myObj.set(othername, 69);
assert(myObj.get!int(othername) == 69);
assert(sample == 69);
}
Ali
Much obliged. Just working on preventing type errors, now. I'll
let you know how it goes
change value of item in BinaryHeap
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 heap, and simply re-insert them, but I cannot find a function that can allow me to remove an arbitrary element Use-case is implementing Visvalingam's algorithm for shape simplification. I need to always select the element (point on shape) of lowest value (area between it and 2 surrounding points), but doing so changes the value (area) of the 2 surrounding points, and they have to be repositioned in the heap..
Re: 'auto' with AA
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 nestedAA[someBaz]); Ali
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
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 --
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Confirmed. --
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com --- I suspect it's new bloody @nogc + auto-inference. So a symbol in phobos is detected as @nogc w/o debug and consequently mangles with 'Ni'. Later in user program it's not-@nogc in debug and mangles differently. Now it should just generate a new instantiation not present in compiled library but somehow it doesn't happen. --
[Issue 3827] Warn against and then deprecate implicit concatenation of adjacent string literals
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;
foreach (const s; [12, 12\t, hello12, -12, 02
0-12, +12, 1.5, 1,000, 1_000,
0x10, 0b1010___00110011,
-0b10101, 0x10.5])
writefln(`isNumeric(%s): %s`, s, s.strip().isNumeric(true));
}
As you see the last example 02 of the first row of the array literal lacks a
comma.
I have found this bug with the DScanner tool.
--
[Issue 12644] Some std.math functions are not yet @nogc
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);
}
--
[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes
https://issues.dlang.org/show_bug.cgi?id=12228 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||pull Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com Summary|Compiler allows 'this' in |Identifiers 'this' and |BaseClassList |'super' should not be ||allowed as base classes --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3505 --
[Issue 9535] incomplete documentation for std.range.recurrence and std.range.sequence
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. --
[Issue 12662] New: std.range.retro is not @nogc
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: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void main() @nogc {
import std.range: retro;
int[] data;
foreach_reverse (x; data) {} // OK
foreach (x; data.retro) {} // Error
}
DMD 2.066alpha gives:
test.d(5,5): Error: @nogc function 'D main' cannot call non-@nogc function
'std.range.retro!(int[]).retro.Result!().Result.front'
--
[Issue 1371] Compiler rejects valid delegate.
https://issues.dlang.org/show_bug.cgi?id=1371 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com Hardware|x86 |All OS|Linux |All --
[Issue 1870] Reproduce offending lines in error messages for string mixins
https://issues.dlang.org/show_bug.cgi?id=1870
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
Something seems to be outputted nowadays:
-
string get()
{
return
int x;
int y;
int z = x + b;;
}
void main()
{
mixin(get());
}
-
test.d-mixin-13(15): Error: undefined identifier b
The only problem is, where is test.d-mixin-13?
--
[Issue 12632] Out of range indexing for tuple subtype emits a bad diagnostic
https://issues.dlang.org/show_bug.cgi?id=12632 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com --- *** This issue has been marked as a duplicate of issue 12093 *** --
[Issue 12096] Allow body to be used as an identifier
https://issues.dlang.org/show_bug.cgi?id=12096 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution|--- |WONTFIX --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Seems like Andrei Walter have come to the conclusion that we won't fix this. Closing. https://github.com/D-Programming-Language/dmd/pull/3227 --
[Issue 12093] bad error message: Error: no [] operator overload for type Tuple!(string, string)
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. *** --
[Issue 10661] Add secureZeroMemory function in Phobos
https://issues.dlang.org/show_bug.cgi?id=10661 David Nadlinger c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #1 from David Nadlinger c...@klickverbot.at --- +1, this is essential for resilient crypto code. --
[Issue 12663] New: Wrong error message for mutation of immutable static array
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
Keywords: diagnostic
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
immutable static int[] data = [1];
static this() {
data.length++;
}
void main() {}
DMD 2.066alpha gives an error message that is both wrong in contents and refers
to the wrong line:
test2.d(1,31): Error: constant 1u is not an lvalue
Expected is an error message like:
test2.d(3,5): Error: cannot modify immutable expression data
--
