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
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
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
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
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; }
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:
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?
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
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 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
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
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.
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)
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 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
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:
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 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
@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 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 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 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
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 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
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 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
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
43 matches
Mail list logo
