Re: Dynamic Ctors ?

[Voitech via Digitalmars-d-learn]

On Monday, 8 February 2016 at 15:09:30 UTC, Kagamin wrote:

http://dpaste.dzfl.pl/1f25ac34c1ee
You need Tuple, not Algebraic. Algebraic stores only one value 
of one type from a set, like Variant.


Thank you for answering. You right if i would want to store all 
types of T.. in an Inner instance. But my conception was bad from 
the beginning. I want to store only one type of value in Inner 
instance. I just wanted to create generic constructor for each of 
Type which is invalid, cause instance holds value of single type 
that's why it is not parametrized by itself.

Re: Things that keep D from evolving?

[NX via Digitalmars-d-learn]

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC  
implementations?


Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast 
(generational and/or concurrent) GC. Some more detailed 
explanations here:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


I see... By any chance, can we solve this issue with GC managed 
pointers? AFAIK, this is what C++/CLR does: There are 2 different 
pointer types, (*) and (^). (*) is the famous raw pointer, second 
one is GC managed pointer. A GC pointer has write barrier (unlike 
raw pointer) so we can have both raw C performance (if we want) 
and fast generational GC or concurrent GC (which are a magnitude 
better than a mark and sweep GC).
As you realized, there is a major problem with this: classes. The 
desicion of making classes reference-type is actually fine 
(+simplicity), but it doesn't really help with the current 
situation, I expect D to be pragmatic and let me decide. Maybe in 
future... Who knows...

Re: How to warn of unused imports?

[Daniel Kozak via Digitalmars-d-learn]

V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  napsáno:

> When I factor out code from my modules, it really, really often 
> leaves import statements that just sit there doing nothing, 
> making it look like my program is more complex than it is. How do 
> I get warned for leaving those, and a list of which ones I can 
> safely remove?

I dont think there is a way right now. But in a future dscanner.
https://github.com/Hackerpilot/Dscanner/issues/134

How to warn of unused imports?

[cy via Digitalmars-d-learn]

When I factor out code from my modules, it really, really often 
leaves import statements that just sit there doing nothing, 
making it look like my program is more complex than it is. How do 
I get warned for leaving those, and a list of which ones I can 
safely remove?

Re: is increment on shared ulong atomic operation?

[Andrea Fontana via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 20:25:44 UTC, Minas Mina wrote:

Just noticed that there's no example.
It's used like

shared(ulong) a;
atomicOp!"+="(a, 1);


Wow, that syntax sucks a lot.



a.atomicOp!"+="(1);

sounds better. You can alias it too.

Re: Bug or intended?

[cy via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 14:15:04 UTC, rsw0x wrote:
I was playing around with alias templates and came across this, 
I reduced it to:


---
struct A(alias C c){

  auto foo(){
return c.i;
  }
}

struct B{
  C c;
  A!c a;
}

struct C{
  int i;
}
---

It gives me a "need 'this' for 'i' of type 'int'" error.


I think the "alias C c" you pass actually must be a value "c" of 
some sort. A!c would have to produce a different A struct, for 
every c value. (as opposed to A!C which works fine.) So, if you 
made B with a C with an i = 23, then you'd have an A!(23) and if 
you made another one with i = 42, you'd have an A!(42).


That doesn't seem very useful, for general integers. Maybe if it 
was an enum of finite, limited size it'd make sense.

Re: Dynamic Ctors ?

[Voitech via Digitalmars-d-learn]

On Monday, 8 February 2016 at 07:08:58 UTC, Voitech wrote:

On Saturday, 6 February 2016 at 23:35:17 UTC, Ali Çehreli wrote:

On 02/06/2016 10:05 AM, Voitech wrote:

> [...]

You can use string mixins (makeCtor and makeCtors):

string makeCtor(T)() {
import std.string : format;

[...]


Thank you very much for answering.
Cheers


Unfortunately this doesn't work as I'am trying to assign value 
from ctor to member something like:


this(%s value){
this.value=value;
}

it gives me
Error: memcpy cannot be interpreted at compile time, because it 
has no available source code.
Probably this is caused by declaration of member which is also 
parametrized with T...

Member is:
Algebraic!(T) value;

So declaration of this mixin constructors are done before 
variable value is declared (compilation)?


Is there any field in class that would contain ctors ? Something 
like __ctors ?
i could try to init this(T... value) constructors in static 
constructor using delegates/functions. Something like:


template Outer(T...){
class Inner{
Algebraic!(T) value;

alias ctor(Type) =Inner delegate (Type value);
static this(){
foreach(Type;T){
ctor!(Type) c={
this.value=value;
};
__ctors~=c; // ?
}

}

}

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Well, the latest Intel CPUs have a theoretical throughput of 
30GB/s... so that makes for up to 30MB/ms.


But language changes are needed, I think.

I also don't quite understand how RC can solve the issue with 
pointers to internal fields in classes.

Re: Things that keep D from evolving?

[thedeemon via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC  
implementations?


Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast 
(generational and/or concurrent) GC. Some more detailed 
explanations here:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

Re: How is D doing?

[Basile Burg via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 11:42:42 UTC, bachmeier wrote:
1. Downloads of the DMD compiler have been fluctuating between 
1000 and 1600 per day:


http://erdani.com/d/downloads.daily.png


To this you can add 75dl per day for ldc:

http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

They'll reach 60K (overlall) this week.

Problem with release build.

[sanjayss via Digitalmars-d-learn]

In the following sample program (which tries to set terminal to 
raw mode and check for key presses), compiling as usual (dmd 
t.d), the program works, but compiling in release mode (dmd 
-release t.d) and the raw mode doesn't seem to work. Where do I 
start looking to figure this out or if it is obvious, what am I 
doing wrong? (In the release mode output, notice the character 
getting echo-ed before the "Got").


MacBook-Pro:$ dmd --version
DMD64 D Compiler v2.069.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
MacBook-Pro:$ dmd t.d
MacBook-Pro:$ ./t
Got: a
Got: b
Got: c
Got: d
Got: q
MacBook-Pro:$ dmd -release t.d
MacBook-Pro:$ ./t
aGot: a
bGot: b
cGot: c
dGot: d
eGot: e
qGot: q
MacBook-Pro:$ cat t.d
import core.thread;
import core.stdc.stdio;
import core.sys.posix.fcntl;
import core.sys.posix.termios;
import std.stdio : writeln;

int oldf;
termios oldt;

void
makeraw()
{
termios newt;

assert(tcgetattr(0, ) == 0);
newt = oldt;

newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN);
newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL | 
IGNCR | IXON | IXOFF);

newt.c_cc[VMIN] = 1;
assert(tcsetattr(0, TCSANOW, ) == 0);

oldf = fcntl(0, F_GETFL, 0);
fcntl(0, F_SETFL, oldf | O_NONBLOCK);
}

void
makecooked()
{
fcntl(0, F_SETFL, oldf);
assert(tcsetattr(0, TCSANOW, ) == 0);
}

void
main(string[] args)
{
int ch;

makeraw();
scope(exit) makecooked();

do
{
while ((ch = fgetc(stdin)) == EOF)
{
Thread.sleep(dur!("seconds")(1));
}
writeln("Got: ", cast(dchar)ch);
} while (ch != 'q');
}

Re: Is this a bug in std.typecons.Tuple.slice?

[Marco Leise via Digitalmars-d-learn]

Am Tue, 09 Feb 2016 00:38:10 +
schrieb tsbockman :

> On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
> > What I like most about your proposal is that it doesn't break 
> > any existing code that wasn't broken before. That can't be 
> > emphasized enough.
> 
> Although I wish more than 3 people had voted in my poll, two of 
> them did claim to need the `ref`-ness of `Tuple.slice`, so I 
> don't think we can just ditch it. (I did not vote.)
> 
> If you guys want to add a return-by-value version, it should be 
> treated as an enhancement, not a bug fix in my opinion.

As mentioned I never used the feature myself and wont vote
for one or the other. Three people with no source code to
exemplify current use of .slice! is indeed not much to base
decisions on and both fixes yield unexpected results in
different contexts that warrant bug reports.

-- 
Marco

Re: How do you reference variables in an AA of Variants?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote:

This:   
double b = 1.0;

Variant[string] aa = ["b": ];

writeln(aa["b"]);

fails with:

Error: cannot implicitly convert expression(["b":]) of type 
double*[string] to VariantN!20u[string]


Helps please!


Use an intermediate to carry the result of &:

double b = 1.0;
Variant vb = 
Variant[string] aa = ["b": vb];
writeln(aa["b"]);

 is a rvalue.
vb is a lvalue.

Re: How do you reference variables in an AA of Variants?

[Ali Çehreli via Digitalmars-d-learn]

On 02/08/2016 07:49 PM, Enjoys Math wrote:

This:
 double b = 1.0;

 Variant[string] aa = ["b": ];

 writeln(aa["b"]);

fails with:

Error: cannot implicitly convert expression(["b":]) of type
double*[string] to VariantN!20u[string]

Helps please!


When initializing the array, you have to use Variant():

import std.stdio;
import std.variant;

void main() {
double b = 1.5;

Variant[string] aa = ["b": Variant()];

writeln(aa);
writeln(aa["b"]);
writeln(*aa["b"].get!(double*));
}

Prints something like the following:

["b":7FFD0104B100]
7FFD0104B100
1.5

Ali

Re: Problem with release build.

[sanjayss via Digitalmars-d-learn]

Ignore this -- this is probably due to how I am doing the 
assert(). In the release build, it is getting compiled out and in 
the process compiling out the tcgetattr and the tcsetattr.




On Tuesday, 9 February 2016 at 05:08:20 UTC, sanjayss wrote:
In the following sample program (which tries to set terminal to 
raw mode and check for key presses), compiling as usual (dmd 
t.d), the program works, but compiling in release mode (dmd 
-release t.d) and the raw mode doesn't seem to work. Where do I 
start looking to figure this out or if it is obvious, what am I 
doing wrong? (In the release mode output, notice the character 
getting echo-ed before the "Got").


MacBook-Pro:$ dmd --version
DMD64 D Compiler v2.069.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
MacBook-Pro:$ dmd t.d
MacBook-Pro:$ ./t
Got: a
Got: b
Got: c
Got: d
Got: q
MacBook-Pro:$ dmd -release t.d
MacBook-Pro:$ ./t
aGot: a
bGot: b
cGot: c
dGot: d
eGot: e
qGot: q
MacBook-Pro:$ cat t.d
import core.thread;
import core.stdc.stdio;
import core.sys.posix.fcntl;
import core.sys.posix.termios;
import std.stdio : writeln;

int oldf;
termios oldt;

void
makeraw()
{
termios newt;

assert(tcgetattr(0, ) == 0);
newt = oldt;

newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN);
newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL 
| IGNCR | IXON | IXOFF);

newt.c_cc[VMIN] = 1;
assert(tcsetattr(0, TCSANOW, ) == 0);

oldf = fcntl(0, F_GETFL, 0);
fcntl(0, F_SETFL, oldf | O_NONBLOCK);
}

void
makecooked()
{
fcntl(0, F_SETFL, oldf);
assert(tcsetattr(0, TCSANOW, ) == 0);
}

void
main(string[] args)
{
int ch;

makeraw();
scope(exit) makecooked();

do
{
while ((ch = fgetc(stdin)) == EOF)
{
Thread.sleep(dur!("seconds")(1));
}
writeln("Got: ", cast(dchar)ch);
} while (ch != 'q');
}

How do you reference variables in an AA of Variants?

[Enjoys Math via Digitalmars-d-learn]

This:   
double b = 1.0;

Variant[string] aa = ["b": ];

writeln(aa["b"]);

fails with:

Error: cannot implicitly convert expression(["b":]) of type 
double*[string] to VariantN!20u[string]


Helps please!

Re: Dynamic Ctors ?

[Kagamin via Digitalmars-d-learn]

http://dpaste.dzfl.pl/1f25ac34c1ee
You need Tuple, not Algebraic. Algebraic stores only one value of 
one type from a set, like Variant.

Re: How to warn of unused imports?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:
How do I get warned for leaving those, and a list of which ones 
I can safely remove?


Remove one, recompile. If it passes, leave it. If not, undo and 
move on to the next one.

Re: Things that keep D from evolving?

[Chris Wright via Digitalmars-d-learn]

On Mon, 08 Feb 2016 11:22:45 +, thedeemon wrote:

> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC implementations?
> 
> easy type casting prevent precise GC.

To expand on this point:

A GC makes a tradeoff between allocating efficiently and deallocating 
efficiently. (And a compiler+runtime makes a tradeoff between generating 
larger binaries that take more time to deal with and being able to 
produce precise garbage collection.)

You can write a GC that allocates each type in its own region of memory. 
Every block has a pointer map associated with it. But this means the 
minimum allocation for each type is one page -- typically 4KB. This is 
bad for applications that have very few instances of each type and many 
types of object allocated.

A simpler thing you can do is write a GC that has two regions of memory, 
one with pointers that might point to GC memory and one without. This 
gets rid of the overhead problem but doesn't allow precise collection.

Alternatively, a language might prevent all casting, even upcasting, for 
any type that might contain pointers. Specifically:

class Foo {}
class Bar : Foo {}
Foo foo = new Bar();  // type error!

This means that the GC doesn't ever need to store the type of an 
allocated object anywhere. It can get the information it needs from a 
stack map ("pointer to Foo is stored in this stack frame at offset 8") 
and a similarly formatted map for allocated types.

It would work, but it's sufficiently constraining that I don't think 
anyone has this in a real programming language.

Re: Can D interface with Free Pascal?

[Basile B. via Digitalmars-d-learn]

On Thursday, 28 January 2016 at 04:26:26 UTC, Taylor Hillegeist 
wrote:
Just curious... I had a thought that perhaps since Objective C 
was a replacement for Pascal on the mac. that they might have 
the same interface. but I'm not savvy enough with fpc to figure 
out how to try it.


As said in the other posts you can link dlls or even object files 
produced by a D compiler. There is the D runtime to initialize 
and finalize, a particular attention must be put on te calling 
conventions, also some stuff like strings must be passed using 
toStringz() or received with fromStringz() (and Pchar() in 
pascal)...


One thing that's interesting is to develop let's say the GUI with 
Lazarus and use a core made in D. When you'll debug your 
application in Lazarus, and if an exception is raised within the 
object or the dll made in D, the integrated debugger will break 
and display the D source directly in Lazarus.


The first time it happend to me, I was **totally mesmerized**...

(I even made a post here: 
https://forum.dlang.org/thread/aeiwsnmsrchgmkbll...@forum.dlang.org "//debugger breaks here": it was the Lazarus debugger who displayed a D source).


But actually it's totally logical, it's just the DWARF debug info 
that indicates the source name...

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
Maybe we could.  But it's never going to happen.  Even if 
Walter weren't fundamentally opposed to multiple pointer types 
in D, it wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


You are of course right, but it isn't an absolute. Nothing 
prevents someone to restrict a D compiler in such a way that you 
can get faster GC.


C++ compilers have lots of optional warnings/errors, so it is 
quite possible. But I suppose those that want it would rather use 
Go, C# or some other GC language than can do ahead of time 
compilation.

Re: Things that keep D from evolving?

[rsw0x via Digitalmars-d-learn]

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:


I see... By any chance, can we solve this issue with GC 
managed pointers?


Maybe we could.  But it's never going to happen.  Even if 
Walter weren't fundamentally opposed to multiple pointer types 
in D, it wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


-Wyatt


Pretty much this.
We can't go a version without code breakage, but also can't 
introduce features that would drastically help the language 
because it would introduce breakage.
i.e, all the great ownership/scope/what-have-you proposals and 
shit like DIP25 gets pushed through instead, then 2 days later it 
gets proven to be worthless anyways. Woops.

Re: Things that keep D from evolving?

[Wyatt via Digitalmars-d-learn]

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:


I see... By any chance, can we solve this issue with GC managed 
pointers?


Maybe we could.  But it's never going to happen.  Even if Walter 
weren't fundamentally opposed to multiple pointer types in D, it 
wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


-Wyatt

Re: How to warn of unused imports?

[Ali Çehreli via Digitalmars-d-learn]

On 02/08/2016 06:35 AM, Adam D. Ruppe wrote:

On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:

How do I get warned for leaving those, and a list of which ones I can
safely remove?


Remove one, recompile. If it passes, leave it. If not, undo and move on
to the next one.


Similarly, I comment out all; then uncomment one by one according to 
compilation errors.


Ali

in a template argument, specify which object member to access?

[cy via Digitalmars-d-learn]

object.member lets me access the member of the object, but what 
if I want to access those members in a generic way, but in a 
different arrangement depending on context? Like if I wanted to 
first follow a tree down, and second priority would be going left 
to right, but then I wanted to first go right, and second 
priority would be going down to up.


struct A {
string up;
string down;
string left;
string right;
}

template goPlaces(D1,D2,D3) {
string go(A a) {
return "go " ~ a.D1 ~ " then go " ~ a.D2 ~ " then go " ~ a.D3;
}
}

import std.stdio;

void main() {
A a = {"north","south","east","west"};
writeln(goPlaces!(up,down,left)(a));
}

Do I just have to use a mixin? Or implement those members as 
indexes in an array, if I want to use them differently?


enum Way { UP, DOWN, LEFT, RIGHT };
struct A {
string[Way.max+1] ways;
}
...

Re: How to warn of unused imports?

[cy via Digitalmars-d-learn]

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for DMD. 
I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside the 
compiler.


http://wiki.dlang.org/DIP50

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Monday, 8 February 2016 at 08:50:17 UTC, Daniel Kozak wrote:

V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  
napsáno:


When I factor out code from my modules, it really, really 
often leaves import statements that just sit there doing 
nothing, making it look like my program is more complex than 
it is. How do I get warned for leaving those, and a list of 
which ones I can safely remove?


I dont think there is a way right now. But in a future 
dscanner. https://github.com/Hackerpilot/Dscanner/issues/134


I don't think that Dscanner will be able to do this soon. Its 
scope is limited to a single module, it's not like DCD, which 
works with the imports and which is able to look-up elsewhere.


For example you'll see this if you try to make an analyzer that 
produces warnings for signed & unsigned comparison. It impossible 
without a bit of semantic (ref: 
https://github.com/Hackerpilot/Dscanner/issues/204).


Otherwise, it sounds like a decent enhancement request for DMD. I 
know other compilers who do this warning.

Re: Things that keep D from evolving?

[Laeeth Isharc via Digitalmars-d-learn]

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:


I see... By any chance, can we solve this issue with GC 
managed pointers?


Maybe we could.  But it's never going to happen.  Even if 
Walter weren't fundamentally opposed to multiple pointer types 
in D, it wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


-Wyatt


I have no special knowledge but strikes this observer that they 
are serious about working on solutions (whether that's a better 
GC or alternatives or both).  But some patience required as its 
not such a straightforward problem and its better to take time 
than rush and make a mistake.  It wasn't all that long ago that 
Andrei quit and I guess he moved across country and it certainly 
takes time to sort out one's home office and find a new working 
pattern.


The discussions in the mailing list are quite interesting 
although beyond my technical knowledge for now.


The GC itself may still be far from perfect but its much better 
than it was, and there are more options now.  I have found emsi 
containers (built on top of Andrei's allocator) pretty nice 
myself for my own use.

Re: in a template argument, specify which object member to access?

[cy via Digitalmars-d-learn]

This is what I have so far. Using mixin(rawstring~templatearg) 
for every time I access the member is kind of cludgy though.


struct A {
string up;
string down;
string left;
string right;
}

template goPlaces(string D1, string D2, string D3) {
string goPlaces(ref A a) {
mixin("a."~D2) = "deetoo";
return "go " ~
mixin("a."~D1) ~ " then go " ~
mixin("a."~D2) ~ " then go " ~
mixin("a."~D3);   
}
}

void main() {
import std.stdio;
A a = {"north","south","east","west"};
writeln(goPlaces!("up","left","down")(a));
writeln(a.left);
}


top postinglol

On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote:
object.member lets me access the member of the object, but what 
if I want to access those members in a generic way, but in a 
different arrangement depending on context? Like if I wanted to 
first follow a tree down, and second priority would be going 
left to right, but then I wanted to first go right, and second 
priority would be going down to up.


struct A {
string up;
string down;
string left;
string right;
}

template goPlaces(D1,D2,D3) {
string go(A a) {
return "go " ~ a.D1 ~ " then go " ~ a.D2 ~ " then go " ~ a.D3;
}
}

import std.stdio;

void main() {
A a = {"north","south","east","west"};
writeln(goPlaces!(up,down,left)(a));
}

Do I just have to use a mixin? Or implement those members as 
indexes in an array, if I want to use them differently?


enum Way { UP, DOWN, LEFT, RIGHT };
struct A {
string[Way.max+1] ways;
}
...

Re: in a template argument, specify which object member to access?

[cy via Digitalmars-d-learn]

On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:

i believe you can use __traits(getMember) there.


Great! Should have refreshed before sending that reply...

I wonder if mixin("a."~member) is better or worse than 
__traits(getMember,a,member)...

Re: in a template argument, specify which object member to access?

[Mengu via Digitalmars-d-learn]

On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote:
object.member lets me access the member of the object, but what 
if I want to access those members in a generic way, but in a 
different arrangement depending on context? Like if I wanted to 
first follow a tree down, and second priority would be going 
left to right, but then I wanted to first go right, and second 
priority would be going down to up.


[...]


i believe you can use __traits(getMember) there.

Re: in a template argument, specify which object member to access?

[Mengu via Digitalmars-d-learn]

On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote:

On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:

i believe you can use __traits(getMember) there.


Great! Should have refreshed before sending that reply...

I wonder if mixin("a."~member) is better or worse than 
__traits(getMember,a,member)...


i think it's a matter of taste and here's how i would do it:

import std.stdio;
import std.array;

struct A {
  string up;
  string down;
  string left;
  string right;
}

string goPlaces(args...)(A a) {
  string[] result;
  foreach (arg; args) {
result ~= __traits(getMember, a, arg);
  }
  return "go " ~ result.join(" then go ");
}

void main() {
  A a = {"north", "south", "east", "west"};
  writeln(goPlaces!("up", "down", "left")(a));
  writeln(goPlaces!("down", "right", "left", "up")(a));
}

// outputs
// go north then go south then go east
// go south then go west then go east then go north

Re: Odd Destructor Behavior

[Matt Elkins via Digitalmars-d-learn]

On Monday, 8 February 2016 at 07:31:07 UTC, Daniel Kozak wrote:

Seems to me too, please report it on issues.dlang.org


Reported: https://issues.dlang.org/show_bug.cgi?id=15661

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
What I like most about your proposal is that it doesn't break 
any existing code that wasn't broken before. That can't be 
emphasized enough.


Although I wish more than 3 people had voted in my poll, two of 
them did claim to need the `ref`-ness of `Tuple.slice`, so I 
don't think we can just ditch it. (I did not vote.)


If you guys want to add a return-by-value version, it should be 
treated as an enhancement, not a bug fix in my opinion.

Re: in a template argument, specify which object member to access?

[cym13 via Digitalmars-d-learn]

On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote:

On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:

i believe you can use __traits(getMember) there.


Great! Should have refreshed before sending that reply...

I wonder if mixin("a."~member) is better or worse than 
__traits(getMember,a,member)...


I think I prefer the mixin version because it doesn't rely on 
compiler internals and is easier to read IMHO but this is very 
questionable.