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
26 matches
Mail list logo
