I just tried to compile an old project and the following failed:
---
enum Paths : string {
bitmapDir = "content/image",
fontDir = "content/font",
soundDir = "content/sound",
...
if (Paths.preferences.exists)
...
---
It turns out members of Paths are no longer
On Sunday, 14 August 2016 at 17:23:06 UTC, Basile B. wrote:
It is private: https://dpaste.dzfl.pl/83fcca84dde3, so the code
you've posted in the first message could be a bug.
Ah, you're correct. I'm not able to use either of them in runtime
code.
The deprecation message also since this
On Sunday, 14 August 2016 at 15:47:16 UTC, Basile B. wrote:
No it's the opposite, only mixins gets the scope of the
instantiation's location.
Right, if it were a mixin, it would get the scope of the
instantiation (the main
module) and `i` would be inacessible.
Since it isn't a mixin, I
Can someone help me understand why the first line is fine, but
the second triggers a deprecation warning for access to a private
variable?
---
import std.traits;
import s;
pragma(msg, hasUDA!(S.getMember_i, attr)); // fine
pragma(msg, hasUDA!(S.getMember!"i", attr)); // deprecated
/++ in
On Saturday, 23 April 2016 at 00:55:07 UTC, rcorre wrote:
On Friday, 22 April 2016 at 10:25:34 UTC, Chris wrote:
On Friday, 22 April 2016 at 09:49:02 UTC, Rene Zwanenburg
wrote:
On Thursday, 21 April 2016 at 16:29:14 UTC, rcorre wrote:
- What happens when you compile a binary without phobos
On Friday, 22 April 2016 at 10:25:34 UTC, Chris wrote:
On Friday, 22 April 2016 at 09:49:02 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 16:29:14 UTC, rcorre wrote:
- What happens when you compile a binary without phobos and
druntime, and with a custom entry point? I've never done
On Thursday, 21 April 2016 at 12:57:36 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 11:54:27 UTC, rcorre wrote:
Thanks for the tip. Here's the linking code it shows:
cc d.o -o d -m64 -L/usr/lib -L/usr/lib32 -Xlinker
--export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker
On Thursday, 21 April 2016 at 09:55:30 UTC, Rene Zwanenburg wrote:
On Thursday, 21 April 2016 at 01:20:27 UTC, rcorre wrote:
s/compile/link
I _can_ compile a D library, but as soon as I try to link
anything compiled with DMD it falls over.
What is dmd's verbose output? (add -v switch)
Some
On Thursday, 21 April 2016 at 01:18:14 UTC, rcorre wrote:
On Wednesday, 20 April 2016 at 19:24:49 UTC, Chris wrote:
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making
On Wednesday, 20 April 2016 at 19:24:49 UTC, Chris wrote:
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding
On Wednesday, 20 April 2016 at 12:48:46 UTC, rcorre wrote:
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding
On Wednesday, 20 April 2016 at 12:04:45 UTC, rcorre wrote:
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit
===
$ dmd /tmp/d.d
/usr/bin/ld: d.o: relocation R_X86_64_32 against
`__dmd_personality_v0' can not be used when making a shared
object; recompile with -fPIC
d.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
--- errorlevel 1
===
I'm seeing the above trying to
@nogc unittest {
int[2] a = [1, 2];
assert(a == [1, 2]); // OK
immutable(int)[2] b = [1, 2];
assert(b == [1, 2]); // fail: array literal may cause
allocation
}
Is there any logic behind allowing the comparison with `a` but
not `b`, or is this a compiler bug?
On Wednesday, 9 March 2016 at 16:53:08 UTC, Xinok wrote:
On Wednesday, 9 March 2016 at 15:39:55 UTC, rcorre wrote:
Still curious as to why it fails; maybe the range is getting
copied at some point? I guess I need to step through it.
That's my suspicion as well. It seems that OnlyResult is
On Wednesday, 9 March 2016 at 14:28:11 UTC, cym13 wrote:
Note that an input range isn't even remotely a container, it's
a way to iterate on a container. As you don't have all elements
at hand you can't sort them, that's why you have to use array
here.
Oh, I think it just clicked. I was
On Wednesday, 9 March 2016 at 14:28:11 UTC, cym13 wrote:
On Wednesday, 9 March 2016 at 12:21:55 UTC, rcorre wrote:
On Wednesday, 9 March 2016 at 09:15:01 UTC, Edwin van Leeuwen
wrote:
I'm not sure why your fix didn't work, but generally I work
around this by converting the OnlyResult into an
On Wednesday, 9 March 2016 at 12:31:18 UTC, Edwin van Leeuwen
wrote:
On Wednesday, 9 March 2016 at 12:21:55 UTC, rcorre wrote:
If you are looking for a lazy uniq that works on non sorted
ranges, I implemented one not to long ago:
On Wednesday, 9 March 2016 at 09:15:01 UTC, Edwin van Leeuwen
wrote:
I'm not sure why your fix didn't work, but generally I work
around this by converting the OnlyResult into an array:
import std.array : array;
assert(only(3,1,2).array.sort.equal(only(1,2,3)));
I'd like to avoid allocating
I was in a situation where I wanted to remove duplicates from an
OnlyResult.
To do this with uniq, I needed to sort it. OnlyResult doesn't
satisfy the template constraints of sort, but this seems easy
enough to fix. I made front, back, and opIndex return by ref.
With this, the following
On Thursday, 11 February 2016 at 04:20:13 UTC, tsbockman wrote:
On Thursday, 11 February 2016 at 03:09:51 UTC, rcorre wrote:
I recently tried compiling enumap with GDC, and found that it
disagrees with DMD on whether a function is @nogc. Here's a
semi-reduced test-case:
Here's an @nogc
On Thursday, 11 February 2016 at 12:41:16 UTC, rcorre wrote:
On Thursday, 11 February 2016 at 04:20:13 UTC, tsbockman wrote:
Using zip and slices guarantees that the structure returned
will be only 5*size_t.sizeof bytes, regardless of the types of
K and V.
I'm on the DMD 2.070 release, so
I recently tried compiling enumap with GDC, and found that it
disagrees with DMD on whether a function is @nogc. Here's a
semi-reduced test-case:
---
import std.range;
import std.traits: EnumMembers;
import std.typecons : tuple, staticIota;
import std.algorithm : map;
struct Enumap(K, V)
The following works:
---
struct Foo { float x; }
auto val(Foo foo) { return foo.x; }
auto val(ref Foo foo, float val) { return foo.x = val; }
unittest {
auto f = Foo();
f.val = 5;
assert(f.val == 5);
}
---
But the following fails to compile with 'val(b) is not an lvalue'.
---
struct
On Friday, 1 January 2016 at 11:59:39 UTC, rcorre wrote:
auto val(T)(ref Bar!T bar, float val) { return bar.x = val; }
Uh, never mind. That `float` should have been `T`. Seems to work
now.
In the following example, it seems like the signatures of fun1
and fun2 should
be equivalent. Both accept a Vector!(T, 2), the only difference
is that fun2
goes through an alias.
struct Vector(T, int N) { }
alias Vector2(T) = Vector!(T, 2);
void fun1(T)(Vector!(T, 2) vec) { }
void
On Sunday, 13 September 2015 at 00:21:22 UTC, Nicholas Wilson
wrote:
there was talk of adding symbol name compression some time ago
( to reduce lib size ( and maybe make ddemangle not fail on
long syms?). This might be the cause of your problems i.e. the
new compiler emitting references to
After upgrading from DMD 2.068.0-1 to DMD 2.068.1-1, my project
began producing a large linker error (when built using dub).
I was able to trace it down to a single line:
target = target.adjacent(Diagonals.yes).randomSample(1).front;
target is of type RowCol
On Thursday, 16 July 2015 at 07:20:16 UTC, Fusxfaranto wrote:
An associative array of Variant[string] ought to do the job
well enough.
http://dlang.org/phobos/std_variant.html
For extra fun, you can implement the '.' style syntax pretty
easily:
---
import std.variant;
struct LuaTable {
Is there any reason why implicit conversion from Foo to Thing is
permitted in a regular method but not in a constructor?
Trying to figure out whether this is a bug or some sort of
constructor-specific safety precaution.
struct Thing {
Foo foo;
alias foo this;
}
class Foo { }
class Bar
On Saturday, 18 July 2015 at 02:28:09 UTC, tcak wrote:
I even am not sure how in the world it allows implicit
conversion from class to struct in fine at all.
The 'alias this' in the struct permits implicit conversion.
I _think_ that is intended behavior, though I admit I'm not
actually sure
On Sunday, 14 June 2015 at 12:36:43 UTC, Adam D. Ruppe wrote:
You can use @property there, but you don't have to because you
can call it with optional parenthesis anyway.
Thanks.
Is there a good reference for the current state of @property?
I know it was hotly debated for awhile (and maybe
Suppose I have a function defined like so:
void foo(int i) { }
intended to be called like:
5.foo
Should it be labeled with @property?
Or is @property only for true member functions?
So I thought this might work:
struct MaybeEmpty(R) if (isInputRange!R) {
private bool _isEmpty;
private R_input;
alias _input this;
this(bool isEmpty, R input) {
_input = input;
_isEmpty = isEmpty;
}
@property bool empty() {
return _isEmpty || _input.empty;
}
}
On Thursday, 14 May 2015 at 06:41:45 UTC, Ali Çehreli wrote:
I am lucky because although the returned type is opaque to me,
I know that it is constructed by a void lambda.
Yeah, in this case I control the container so I may just add an
emptySlice property, but it does seem like it might be
On Thursday, 14 May 2015 at 14:57:26 UTC, Idan Arye wrote:
How about a more flexible solution?
http://dpaste.dzfl.pl/2f99cc270651
Neat, thanks!
On Thursday, 14 May 2015 at 18:44:58 UTC, Steven Schveighoffer
wrote:
It depends on the guts of MyContainer.Range.
I'm assuming
On Friday, 15 May 2015 at 03:22:43 UTC, rcorre wrote:
On Thursday, 14 May 2015 at 14:57:26 UTC, Idan Arye wrote:
How about a more flexible solution?
http://dpaste.dzfl.pl/2f99cc270651
Neat, thanks!
The range I don't pick may be an expression that would fail, so I
tweaked it to:
I've run into this situation a lot:
I have a function that returns a range (in this case, a slice of
a custom container).
In some cases, the function needs to return an empty range.
It sounded like takeNone was what I wanted:
@nogc auto fun() {
return (some_condition) ? getRange() :
Actually, this doesn't even seem to work with a custom range:
import std.range;
import std.stdio;
import std.algorithm;
struct MyContainer {
@nogc auto opSlice() {
struct Range {
@property bool empty() { return true; }
@property int front() { return 9; }
I ran into this infuriatingly confusing situation just now:
static assert(is(typeof(Parent.init.new Child) == Parent.Child));
// fine
alias P = Parent;
alias T = Parent.Child;
static assert(is(typeof(P.init.new T) == T)); // nope!
Wat???
After much confusion, I finally discovered this in
On Saturday, 25 April 2015 at 09:56:25 UTC, tired_eyes wrote:
A brief look at code.dlang.org gives us 7 (!) additional JSON
libraries. Keeping in mind that D community isn't so huge, I
think I'm not the only person struggling with std.json. Are
there any plans on upgrading it?
See
On Tuesday, 24 March 2015 at 16:41:28 UTC, Rene Zwanenburg wrote:
Should not be necessary. privately import Flag and make a
public alias:
module a;
import std.typecons : Flag;
alias SomeFlag = Flag!SomeFlag;
SomeFlag.Yes and SomeFlag.No should be usable in other modules
without additional
If I am developing a library and some of my functinos take a
std.typecons.Flag as an argument, should I 'public import
std.typecons: Flag, Yes, No'?
It seems like it would be a pain for users of the library to have
to import this separately whenever they use my library, but I'm
not sure what
43 matches
Mail list logo
