Re: The compiler can't "see" an inner class

2019-10-27 Thread Emmanuelle via Digitalmars-d-learn

On Sunday, 27 October 2019 at 19:54:06 UTC, Simen Kjærås wrote:

It's a bug:

interface A {
interface B : A {
class C : B {
}
}
// Fails: no property 'C' for type 'foo.A.B'
void inside(A.B.C c) { }
}
// Works
void outside(A.B.C c) { }

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

--
  Simen


Yikes! Thanks for submitting the issue to bugzilla :)


The compiler can't "see" an inner class

2019-10-27 Thread Emmanuelle via Digitalmars-d-learn

Hello! See snippet:

---
interface AST
{
static interface Expr : AST
{
final static class Name : Expr
{
override void accept(AST.Visitor v) { 
v.visitName(this); }

}
}

final static class Visitor
{
void visitName(AST.Expr.Name name);
}

void accept(AST.Visitor v);
}
---

If you try to compile that, dmd v2.088.0 complains:

---
Error: no property Name for type onlineapp.AST.Expr
---

How come? It's defined right there. I would really like some 
pointers on this, thanks!


Why is the fPIC switch missing?

2019-09-22 Thread Emmanuelle via Digitalmars-d-learn
Hello. My problem is exactly what it says on the title: my dmd 
(windows 7, x64) doesn't seem to have -fPIC:


---

dmd -fPIC

Error: unrecognized switch '-fPIC'
   run `dmd` to print the compiler manual
   run `dmd -man` to open browser on manual
---

`dmd --help` also doesn't have anything about fPIC. Sorry if I'm 
being dense but why is that? Is it only available on Linux?


Thank you!


Re: Why is the fPIC switch missing?

2019-09-22 Thread Emmanuelle via Digitalmars-d-learn
Forgot to say: dmd v2.088.0. Also, weirdly enough, `dmd 
--version` outputs `DMD32 D Compiler v2.088.0-dirty`. Why is 
"dirty" there?


Re: Transform a function's body into a string for mixing in

2019-06-21 Thread Emmanuelle via Digitalmars-d-learn

On Friday, 21 June 2019 at 15:54:35 UTC, Adam D. Ruppe wrote:

On Friday, 21 June 2019 at 15:42:56 UTC, Emmanuelle wrote:

[...]


This sounds very similar to something I hacked together a while 
ago and recently wrote about making cleaner code:


https://forum.dlang.org/post/ekbyseslunvmudkhl...@forum.dlang.org

The idea here was to do a pass-by-value lambda. Usage:

---
auto bar(T)(T x) @nogc
{
return x(10);
}

auto foo(int x) @nogc
{
auto f = lambda!(x, q{ (int y) { return x + y; } });
return f;
}

void main()
{
import std.stdio;
writeln(foo(15)(10));
}
---

Magic implementation:

---
template lambda(Args...) {
static struct anon {
static foreach(i; 0 .. Args.length - 1)
			mixin("typeof(Args[i]) " ~ __traits(identifier, Args[i]) ~ 
";");

auto opCall(T...)(T t) {
return mixin(Args[$-1])(t);
}
this(T...)(T t) {
this.tupleof = t;
}
}

anon lambda() {
anon a;
// copy the values in
a.tupleof = Args[0 .. $-1];
return a;
}
}
---



You could convert that into a regular delegate too, so it works 
with non-template consumers, by generating a non-templated 
opCall and taking its address.


Oh wow, that's pretty awesome. Too bad it seems the token string 
around the lambda is unavoidable, but it's not a big deal I 
think. In any case thanks, you snippet helped me figure out the 
template I wanted without overuse of strings!


Re: Transform a function's body into a string for mixing in

2019-06-21 Thread Emmanuelle via Digitalmars-d-learn

On Thursday, 20 June 2019 at 20:38:48 UTC, Dennis wrote:

On Thursday, 20 June 2019 at 19:09:11 UTC, Emmanuelle wrote:
Is there any trait or Phobos function for transforming a 
function/delegate/lambda/whatever's body into a string 
suitable for `mixin(...)`? For example:


See:
https://forum.dlang.org/post/kozwskltzidfnatbp...@forum.dlang.org


If not, is there any way to do this _without_ using strings?


Depends on what you are trying to achieve with mixing in 
function body code. If you just want to execute the function 
code, you can just call it (obviously), so I assume you want 
dynamic scoping (that global variables are overridden by local 
variables from the caller) or something?


Yeah, I want to be able to basically use mixin templates but with 
expressions instead, with the code being executed on the scope of 
the caller, not the callee; but it seems that's impossible 
without passing strings. For example, I recently hit an issue 
with closure scoping 
(https://forum.dlang.org/post/rnxebjcfpmyzptpwz...@forum.dlang.org) that can be worked around by using IIFEs; I thought, hey, maybe I could make a mixin that turns, say, this (taking the example from the post I just linked):


---
((x) => (int i) { nums[x] ~= i; })(x);
---

into this:

---
mixin(capture!(x, (int i) { nums[x] ~= i; });
---

where the variables I need captured go first there (in this case, 
only `x`). Of course, that doesn't work unless I use strings 
everywhere:


---
mixin(capture!("x", q{(int i) { nums[x] ~= i; }});
---

which I find rather ugly and inconvenient.

The technique you linked seems interesting but also loads of work 
so I'll just give up on this idea for now lol. Thanks though!


Transform a function's body into a string for mixing in

2019-06-20 Thread Emmanuelle via Digitalmars-d-learn

Hello!

Is there any trait or Phobos function for transforming a 
function/delegate/lambda/whatever's body into a string suitable 
for `mixin(...)`? For example:


---
__traits(getBody, (int a, int b) => a + b); // returns "(int a, 
int b) => a + b"
// or maybe just "a + 
b"

---

If not, is there any way to do this _without_ using strings? They 
are very inconvenient and could hide errors.


Thanks!


Re: What's the difference between DIP25 and DIP1000?

2019-06-18 Thread Emmanuelle via Digitalmars-d-learn

On Tuesday, 18 June 2019 at 21:57:32 UTC, Jonathan M Davis wrote:

-snip-


Thank you, it's clear to me now :)



What's the difference between DIP25 and DIP1000?

2019-06-18 Thread Emmanuelle via Digitalmars-d-learn
Hi, I've been reading about DIP25 and DIP1000 and I'm not quite 
sure if I understand the difference between the two—is DIP1000 
supposed to be a rework of DIP25? And what's the difference 
between `return ref` and `return scope`? Also, will there be any 
compiler version where `-preview=dip25` and/or `-preview=dip1000` 
are the default?


Thanks!


Re: Strange closure behaviour

2019-06-15 Thread Emmanuelle via Digitalmars-d-learn

On Saturday, 15 June 2019 at 16:29:29 UTC, Rémy Mouëza wrote:
I don't know if we can tell this is a compiler bug. The same 
behavior happens in Python. The logic being variable `x` is 
captured by the closure. That closure's context will contain a 
pointer/reference to x. Whenever x is updated outside of the 
closure, the context still points to the modified x. Hence the 
seemingly strange behavior.


I come from Ruby, where it works as I expected, so I assumed all 
languages would work like that; but then, D surprised me, and 
now, Python too, and apparently a whole bunch of other languages 
(which is honestly kinda disheartening since I like throwing 
lambdas everywhere.)




Re: Strange closure behaviour

2019-06-14 Thread Emmanuelle via Digitalmars-d-learn

On Saturday, 15 June 2019 at 00:30:43 UTC, Adam D. Ruppe wrote:

On Saturday, 15 June 2019 at 00:24:52 UTC, Emmanuelle wrote:

Is it a compiler bug?


Yup, a very longstanding bug.

You can work around it by wrapping it all in another layer of 
function which you immediately call (which is fairly common in 
javascript):


funcs ~= ((x) => (int i) { nums[x] ~= i; })(x);

Or maybe less confusingly written long form:

funcs ~= (delegate(x) {
return (int i) { nums[x] ~= i; };
})(x);

You write a function that returns your actual function, and 
immediately calls it with the loop variable, which will 
explicitly make a copy of it.


Oh, I see. Unfortunate that it's a longstanding compiler bug, but 
at least the rather awkward workaround will do. Thank you!


Strange closure behaviour

2019-06-14 Thread Emmanuelle via Digitalmars-d-learn

Take a look at this code:

---
import std.stdio;

void main()
{
alias Func = void delegate(int);

int[][] nums = new int[][5];
Func[] funcs;
foreach (x; 0 .. 5) {
funcs ~= (int i) { nums[x] ~= i; };
}

foreach (i, func; funcs) {
func(cast(int) i);
}

writeln(nums);
}
---

(https://run.dlang.io/is/oMjNRL)

The output is:

---
[[], [], [], [], [0, 1, 2, 3, 4]]
---

Personally, this makes no sense to me. This is the result I was 
expecting:


---
[[0], [1], [2], [3], [4]]
---

Why is it "locking" the bound `x` to the last element? It seems 
like the compiler is overwriting the closure for `x`, somehow. 
So, I'm wondering why D is doing that. Is it a compiler bug? Or 
is this the expected behaviour?


Re: Ordering of UDAs

2019-04-22 Thread Emmanuelle via Digitalmars-d-learn

On Monday, 22 April 2019 at 19:32:27 UTC, Adam D. Ruppe wrote:

On Monday, 22 April 2019 at 19:02:57 UTC, Emmanuelle wrote:
Hello! Does `__traits(getAttributes, ...)` return UDAs in the 
order they were declared in the source code, or is it 
unspecified?


I think that is defined:

https://dlang.org/spec/attribute.html#uda

"If there are multiple UDAs in scope for a declaration, they 
are concatenated: "


and the example shows it in order.

It also says

"Whether the attributes are values or types is up to the user, 
and whether later attributes accumulate or override earlier 
ones is also up to how the user interprets them. "


Which implies it must be in order so you can make that 
determination.


It isn't as specific as I'd like, but it sure sounds like it 
must be in order to me.


Alright, that makes enough sense to me. Thank you!


Ordering of UDAs

2019-04-22 Thread Emmanuelle via Digitalmars-d-learn
Hello! Does `__traits(getAttributes, ...)` return UDAs in the 
order they were declared in the source code, or is it unspecified?