Re: auto: useful, annoying or bad practice?

[Jonathan M Davis via Digitalmars-d]

On Sunday, May 20, 2018 14:33:16 I love Ice Cream via Digitalmars-d wrote:
> On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
> > The return type for range-oriented functions in std.algorithm
> > is usually not terribly useful.
>
> So the first question that comes to my mind are what are the
> 'rules' of the output. Which is really what typing is. It's a
> series of rules. Your object is allowed to call these
> methods/properties. It is 'this' size. Languages have generic
> returns. D is not the only language with a concept of returning a
> 'compiler determined type'. But the rules are always baked into
> the API. If it's not, it's a design failure and more thought
> should be put into it.
>
> The only place I wouldn't be so strict with auto returns is in
> private methods. However, I still might tell someone to think
> about what they are trying to return there. It's not an
> unimportant piece of the API.

That's where you get into a combination of needing good documentation and
needing to know what set of traits to use to test the type to see what
functionality it has. But for better or worse, asking a type what it can do
is a key piece of Design by Introspection. The result can be extremely
powerful, as Andrei has talked about on multiple occasions (I'd suggest
watching his dconf 2015 talk about it if you haven't), but it does place a
higher burden on the programmer to figure out how to use a type. So, there
are pros and cons. Ultimately, auto can be extemely useful, and much of what
we do with D really wouldn't be reasonably feasible without it, but it also
needs to be used intelligently, because while it does bring some serious
benefits, it can be at the cost of clarity if used poorly.

- Jonathan M Davis

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Yuxuan Shui via Digitalmars-d]

On Sunday, 20 May 2018 at 14:39:28 UTC, Jonathan M Davis wrote:
Well, constructors are one of the few places that the compiler 
attempts flow analysis for stuff other than optimization, 
because it pretty much has to in order to do what the language 
needs. And no, it's not very sophisticated about it, because 
it's simpler to guarantee correctness that way. It also 
highlights why Walter is usually against doing much in the way 
of flow analysis. By designing the language such that it 
doesn't need much flow analysis, you mostly avoid problems like 
this. Unfortunately, it becomes more or less impossible to 
completely avoid it in constructors when you have const or 
immutable members, so the compiler does have to do some flow 
analysis in constructors. And it seems that Walter's solution 
in this sort of situation is to err on the side of having the 
compiler be stupid in order to avoid better guarantee 
correctness.


Not being a compiler expert, I can't really comment on what the 
best approach would be here, but I know that Walter is 
typically against flow analysis at the semantic pass level 
precisely because it's very hard to get right, and it's always 
a battle between having it be sophisticated enough to not get 
in the programmers way and having it actually be guaranteed to 
be correct. As I understand it, flow analysis in stuff like the 
optimizer is _much_ easier, because the constructs you're 
dealing with are much easier. That's also why Walter and Andrei 
really like to design advanced language features in terms of 
lowering into simpler features (e.g. the use of destructors and 
scope statments all get lowered to try-catch-finally blocks). 
It's much easier to guarantee correctness with simpler features.


As for this particular case, I expect that the best course of 
action is to report it in bugzilla and see what Walter thinks 
is the best approach. I can comment on Walter's basic approach 
and reasoning based on what he's said about these issues in the 
past, but I can't way what his response would be to this 
particular example.


- Jonathan M Davis


I would argue that the best approach is to design the language to 
avoid flow analysis as much as possible. But for places that need 
it, the compiler should do as best as it can.

Re: Sealed classes - would you want them in D? (v2)

[Dave Jones via Digitalmars-d]

On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel 
wrote:


But in D, everything is your friend - you don't get to manage


You want to be taken seriously and yet you repeat false 
statements over and over again.



There is absolutely no reason why D cannot have both (the 
current way D does it, and the C++ way). It's obviously 
technically possible.


Being technically possible or even easy to implement is not an 
argument for including something.



It's obvious it would attract a great deal more programmers to 
D.


Pure conjecture. You don't know why people choose not to use D, 
you know why you choose not to use it. Assuming your opinion is 
shared by all these supposed people is at best naive at worst an 
indication of narcissism.


I'll assume for now that you are young, idealistic and naive.


It doesn't really complicate the language at all - that's just 
an excuse not to change. And, it's obvious, that protecting the 
interface would result in better quality software. It's a core 
fundamental principle of quality software.


It's just a matter of getting more diverse people into the D 
'community'.


Yes because if a group of people don't accept your argument about 
something obviously there is something wrong with them.


OK it's starting to look more like narcissism.


But I get the feeling that's not what most D people want. The 
status quo is pretty comfortable for many, it seems.


No shit... you're just getting that feeling now? You remind me of 
my teenage son, it takes about 100 times of telling him something 
before it sticks in his head.


Let me ask you this...

How do you get comfortable with something? By using it, trying 
it, and finding that it works. You don't get comfortable with 
having a stone in your shoe, so if this feature was the nightmare 
you say it is all these people using D wouldn't be OK with it.


But again it's utterly pointless because you cannot grasp that. 
You are unable to even consider that something "other" might 
work. You are a zealot in that respect, that's why you 
exaggerate, misrepresent the other side of the argument, predict 
doom for the heathens, and never budge on your position.


Anyway... feel free to misrepresent what I've said, engage in 
hyperbole, snip the parts you cant argue with, speak for all the 
people who chose not to use D, tell D it's doomed if they don't 
do what you say, it'll never be popular, that it's all idiotic. 
Etc...

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Jonathan M Davis via Digitalmars-d]

On Sunday, May 20, 2018 10:56:27 Yuxuan Shui via Digitalmars-d wrote:
> On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
> > because it tends to become very difficult to get right in all
> > cases and results in situations where the programmer is forced
> > to do something in order to make the compiler shut up
>
> Well, doesn't this post show exactly this problem, and that's
> because the compiler is too dumb?
>
> Making the compiler smarter will only decrease the number of
> these cases.

Well, constructors are one of the few places that the compiler attempts flow
analysis for stuff other than optimization, because it pretty much has to in
order to do what the language needs. And no, it's not very sophisticated
about it, because it's simpler to guarantee correctness that way. It also
highlights why Walter is usually against doing much in the way of flow
analysis. By designing the language such that it doesn't need much flow
analysis, you mostly avoid problems like this. Unfortunately, it becomes
more or less impossible to completely avoid it in constructors when you have
const or immutable members, so the compiler does have to do some flow
analysis in constructors. And it seems that Walter's solution in this sort
of situation is to err on the side of having the compiler be stupid in order
to avoid better guarantee correctness.

Not being a compiler expert, I can't really comment on what the best
approach would be here, but I know that Walter is typically against flow
analysis at the semantic pass level precisely because it's very hard to get
right, and it's always a battle between having it be sophisticated enough to
not get in the programmers way and having it actually be guaranteed to be
correct. As I understand it, flow analysis in stuff like the optimizer is
_much_ easier, because the constructs you're dealing with are much easier.
That's also why Walter and Andrei really like to design advanced language
features in terms of lowering into simpler features (e.g. the use of
destructors and scope statments all get lowered to try-catch-finally
blocks). It's much easier to guarantee correctness with simpler features.

As for this particular case, I expect that the best course of action is to
report it in bugzilla and see what Walter thinks is the best approach. I can
comment on Walter's basic approach and reasoning based on what he's said
about these issues in the past, but I can't way what his response would be
to this particular example.

- Jonathan M Davis

Re: auto: useful, annoying or bad practice?

[I love Ice Cream via Digitalmars-d]

On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you 
what type the return value is.


This might sound a little hard, but that's probably a fundamental 
failure of the D language and explains some of the poor tooling 
around the language.

[Issue 18683] std.containers.rbtree.RedBlackTree has opEquals but no toHash

[d-bugmail--- via Digitalmars-d-bugs]

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

vladvi...@gmail.com changed:

   What|Removed |Added

 CC||vladvi...@gmail.com
   Assignee|nob...@puremagic.com|vladvi...@gmail.com

--

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Daniel N via Digitalmars-d]

On Sunday, 20 May 2018 at 10:56:27 UTC, Yuxuan Shui wrote:

On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
because it tends to become very difficult to get right in all 
cases and results in situations where the programmer is forced 
to do something in order to make the compiler shut up


Well, doesn't this post show exactly this problem, and that's 
because the compiler is too dumb?


Making the compiler smarter will only decrease the number of 
these cases.


There is one construct which is guaranteed to run at the end...

  this(ExceptionType t, long rowsNum, string file = __FILE__, 
size_t line = __LINE__) pure @safe {


type = t;

string msg;
scope(exit) super(msg, file, line); // w00t

Re: Reserved 1.0.0

[Paolo Invernizzi via Digitalmars-d-announce]

On Sunday, 20 May 2018 at 09:15:12 UTC, Andrea Fontana wrote:

On Sunday, 20 May 2018 at 07:33:39 UTC, Fra Mecca wrote:
On Wednesday, 16 May 2018 at 08:38:05 UTC, Andrea Fontana 
wrote:
I released another small library on behalf of the company I 
work for (http://lab.2night.it). It is called "reserved", and 
it's a small library you can use to run your D 
webpages/service.


It is focused on simplicity (no dependencies) and fast setup. 
It use scgi to interface itself with nginx/apache/etc through 
unix sockets.


More info: http://code.dlang.org/packages/reserved

Comments are welcome.

Andrea Fontana


Ciao Andrea,
it is very nice to see an italian company (being an italian 
myself) publishing in the forum and using D.

Thanks for the contribution.

Francesco


We should try to spread the word :)

Andrea


Concordo :-)

/Paolo

Re: auto: useful, annoying or bad practice?

[I love Ice Cream via Digitalmars-d]

On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
The return type for range-oriented functions in std.algorithm 
is usually not terribly useful.


So the first question that comes to my mind are what are the 
'rules' of the output. Which is really what typing is. It's a 
series of rules. Your object is allowed to call these 
methods/properties. It is 'this' size. Languages have generic 
returns. D is not the only language with a concept of returning a 
'compiler determined type'. But the rules are always baked into 
the API. If it's not, it's a design failure and more thought 
should be put into it.


The only place I wouldn't be so strict with auto returns is in 
private methods. However, I still might tell someone to think 
about what they are trying to return there. It's not an 
unimportant piece of the API.

auto & class members

[Robert M. Münch via Digitalmars-d-learn]

I use the D RX lib [1] and can create a filtered stream using the auto keyword:

struct a {
SubjectObject!myType myStream;
??? mySubStream;
}

void myfunc(){
a myA = new a();

auto mySubStream = a.myStream.filter!(a => a == myMessage);
...
}

The problem is, that I don't find out what the type of mySubStream is, 
which I would like to make a member of the struct, so that I can 
reference it outside the function too.


How can I find out the type of an auto? This here seems to be a pretty 
complicated templated, nested type, whatever result.


[1] https://github.com/lempiji/rx

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[Yuxuan Shui via Digitalmars-d]

On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
because it tends to become very difficult to get right in all 
cases and results in situations where the programmer is forced 
to do something in order to make the compiler shut up


Well, doesn't this post show exactly this problem, and that's 
because the compiler is too dumb?


Making the compiler smarter will only decrease the number of 
these cases.

[Issue 18819] DMD compilation crash

[d-bugmail--- via Digitalmars-d-bugs]

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

Nathan S.  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18871

--

[Issue 18871] DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

Nathan S.  changed:

   What|Removed |Added

 CC||n8sh.second...@hotmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18819

--- Comment #5 from Nathan S.  ---
See issue #18819.

--

Re: vibe.d 0.7.33 maintenance release

[Sönke Ludwig via Digitalmars-d-announce]

Am 18.05.2018 um 16:00 schrieb Seb:

On Friday, 18 May 2018 at 13:46:45 UTC, Márcio Martins wrote:

On Wednesday, 16 May 2018 at 08:48:15 UTC, Sönke Ludwig wrote:
Being the final public release on the 0.7.x branch, this version on 
DMD 2.068.2 up to DMD 2.080.0 and LDC 1.9.0. It includes some major 
fixes and improvements backported from the 0.8.x branch. Since this 
marks the last 0.7.x release, all code depending on it should now be 
upgraded to 0.8.3 or later.


Change log:


DUB package:



Comparing with 0.7.x, how production-ready would you say the 0.8.x 
branch is, and what are the main advantages?


Thank you for the awesome work!


I think I can try to answer this for you.
0.8.x has been in production use for almost a year now.

There have been tons of improvements in the API, performance and new 
functionality, so it's hard to boil down individual items. The full 
changelog is here:


http://vibed.org/blog/posts/vibe-release-0.8.0

The biggest change is probably that 0.8 now uses subpackages and the new 
vibe-core package is available for opt-in usage.
Vibe-core is a pure D replacement of the old libevent-based 
event-handling (that's simplified because the actual logic is done by 
eventcore and it contains more functionality too).
Anyhow, there have been a few regressions when vibe.d switched to use 
the new vibe-core in 0.8.3, but funnily it also fixed quite a few 
existing issues with libevent.
So tl;dr: it's safe to upgrade and if you run into any immediate 
troubles, stick to the old libevent for one or two releases (it can be 
selected via the vibe-core subconfiguration).


To add to this, when using the libevent driver, the major changes are 
mainly just type system related (`@safe` and `nothrow` support), so in 
terms of functionality and risk of regressions it is probably safe to 
say that it is not much different than a 0.7.x point release.


The new vibe-core module also runs fine in most contexts, but seems to 
amplify a GC memory consumption/leak issue (visible in the DUB registry) 
and there is still an unresolved report of performance issues in the 
HTTP client (which I couldn't reproduce so far). So this should still be 
used with care in production - on the other hand, any controlled 
real-world exposure is of course highly desirable in order to pinpoint 
any remaining issues.


As Sebastian pointed out, it does fix quite a number of existing, but 
rarely encountered, issues that exist in the libevent implementation, 
because it uses a much more robust approach to fiber scheduling. It also 
has the potential for much better performance, although that is 
currently still nullified by some implementation choices in the HTTP 
server code.


Another big improvement is the diet-ng library, which uses less 
compile-time memory and is a lot more flexible than the old 
`vibe.textfilter.diet` module.

[Issue 18819] DMD compilation crash

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #3 from Mike Franklin  ---
I can reproduce this at run.dlang.io, but I can't reproduce it locally from
DMD-Head (Linux 64-bit).  DMD-Head gives me this:

main.d(19): Error: false has no effect
main.d(34): Error: template instance `main.emplaceInitializer!(S)` error
instantiating
main.d(24):instantiated from here: emplaceRef!(Problem[4])
main.d(15):instantiated from here: emplaceRef!(Problem[4], Problem)

--

[Issue 18885] New: statfs struct was changed in FreeBSD 12

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18885
   Summary: statfs struct was changed in FreeBSD 12
   Product: D
   Version: D2
  Hardware: x86_64
OS: FreeBSD
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: freeslav...@gmail.com

core.sys.posix.sys.statvfs still has the declaration for FreeBSD 11.
That leads to segfeault when calling statfs function because of structure's
size mismatch.

Should we just update statfs_t declaration for FreeBSD (and drop support for
FreeBSD 11) or dispatch somehow?

--

Re: Can I infer the type from this?

[Alex via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 03:16:39 UTC, Dr.No wrote:


Oh, my bad: I totally forgot a crucial thing on question: I 
want this to work with a static member, for example, call 
myTemp like this myTemp!(C.a) I don't mind if I to pass the 
type as parameter somehow, like myTemp!(C, C.a) or 
myTemp!(C)(C.a) but I do need to pass a symbol as parameter, 
hence I'm using alias template parameter.


Still not sure, if I get you right...

´´´
import std.stdio;

void main() { auto res = myTemp!(C.s); }

class C { static size_t s; }

template myTemp(alias s) { enum myTemp = 
templateFunction!(typeof(s))(s.stringof); }


int templateFunction(T)(string targetMembername)
{
static assert(is(T == size_t));
assert(targetMembername == "s");
return 42;
}
´´´

In general, I'm not sure, how you want to get a type of a general 
symbol (this is what templateFunction should do, isn't it?) as it 
could be a template or a value parameter for example.
However, I tried these cases, and typeof yields something 
reasonable then. In particular, it still did compile and yields 
something which could be checked against...

[Issue 18826] [inline asm] Wrongcode for mov

[d-bugmail--- via Digitalmars-d-bugs]

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

Stefan Koch  changed:

   What|Removed |Added

   Priority|P1  |P2
   Severity|enhancement |blocker

--

Re: auto & class members

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, May 20, 2018 16:30:10 Robert M. Münch via Digitalmars-d-learn 
wrote:
> I use the D RX lib [1] and can create a filtered stream using the auto
> keyword:
>
> struct a {
>   SubjectObject!myType myStream;
>   ??? mySubStream;
> }
>
> void myfunc(){
>   a myA = new a();
>
>   auto mySubStream = a.myStream.filter!(a => a == myMessage);
>   ...
> }
>
> The problem is, that I don't find out what the type of mySubStream is,
> which I would like to make a member of the struct, so that I can
> reference it outside the function too.
>
> How can I find out the type of an auto? This here seems to be a pretty
> complicated templated, nested type, whatever result.
>
> [1] https://github.com/lempiji/rx

In cases like this, typeof is your friend. e.g. something like

typeof(myStream.filter!(a => a == myMessage)) mySubStream;

though you might have trouble with the lambda being subtly different type
even if you replace myMessage in it with something that will work in the
scope that mySubStream is being declared. However, that could be fixed by
doing something like replacing the lambda with a free function or just
creating a function that returns what you want to assign to mySubStream.
Then you could just do something like

typeof(myHelperFunc(myStream)) mySubStream;

The exact solution can get a bit annoying in cases like this (it's arguably
the biggest downside to auto returns), but typeof does provide a way out if
you can get the expression to it to work. It is easier with local variables
than member variables though, since you don't necessarily have everything
you want to use in the expression that will give the variable its value
available at the point that the variable is declared - but that's why
a helper function can help, since it provides a way to encapsulate the
expression and reuse it between the assignment and the declaration.

- Jonathan M Davis

[Issue 18882] __gshared not displaying in debuginfo

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Rainer Schuetze  ---
The debug info contains the "pretty" name, i.e. the fully qualified name, even
for extern(C++) symbols. Otherwise you would have to guess the linkage and type
as it is part of the mangled name.

What could be possible is to inspect all symbol at startup and create a map
using the unqualified name as key. That might have a number of conflicts,
though.

--

[Issue 18884] New: getSymbolsByUDA fails on AliasSeq members

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18884
   Summary: getSymbolsByUDA fails on AliasSeq members
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

The following code started failing after DMD 2.078:

unittest {
import std.meta;
import std.traits;

struct X {
alias A = AliasSeq!(ulong, uint);
}

alias x = getSymbolsByUDA!(X, X);
}


DMD 2.080.0 produces this error:


/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/traits.d(8377): Error:
template `std.meta.Alias` does not match any template declaration
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/traits.d(8194): Error:
template instance `std.traits.getSymbolsByUDAImpl!(X, X, "A")` error
instantiating
onlineapp.d(9):instantiated from here: `getSymbolsByUDA!(X, X)`

The flawed line appears to be here: `alias member = Alias!(__traits(getMember,
symbol, names[0]));`

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Rainer Schuetze  ---
It seems I've messed up the defaults between Visual D and mago: you have to
enable it in Tools->Options->Debugger->Mago. I think that being disabled is
actually the better default as the vtable yields no additional information for
most people.

Unfortunately that build is also broken, as it tries to show [0] multiple times
and fails.

--

Re: Override member variables

[Gheorghe Gabriel via Digitalmars-d]

On Sunday, 20 May 2018 at 03:02:28 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 18:09:56 UTC, Gheorghe Gabriel 
wrote:

And of course, you cannot override private members.


wtf!

what do you mean we cannot override private members!


I mean:

module base;

class Base {
protected int x = 1;
private int y = 2;
}

module a;

class A : Base {
override int x = 7;
override int y = 12; // error: y is not accessible
}

Re: Examples/tutorials for OpenGL games which works out-of-the-box on linux

[rikki cattermole via Digitalmars-d-learn]

On 20/05/2018 8:06 PM, Prokop Hapala wrote:

Hi,

I'm looking for examples of OpenGL games which I can use as templates 
for making my own stuff. But I'm quite discouraged that everything I 
found on github is probably outdated and fails to compile. Since I'm not 
very familiar with dub environment I don't feel able to correct the 
errors in dependences etc.


e.g.:

* https://github.com/Circular-Studios/Dash (depends on old version of 
vibe.d, when update the  dub.json it gives this error:
source/dash/components/mesh.d(8,19): Error: module `stream` is in file 
'std/stream.d' which cannot be read


Not a dub issue, the module was removed from Phobos.

* https://github.com/d-gamedev-team/opengl-tutorials - depends on some 
libs like `glad-drey,glfw-drey,glwtf-dray` which are perhaps old 
versions of Derelict bindings, but I won't try to set it up


Not registered on dub repo. I don't think it was ever completed.

* https://github.com/Extrawurst/unecht - There is no setup/build readme, 
when I just hit `dub run` I get errors about missing parts
No package file found in 
/home/prokop/git_SW/_Dlang/unecht/submodules/tharsis.prof/, expected one 
of dub.json/dub.sdl/package.json


$ dub build --config=app
Should work for the application.

Tharsis.prof does have a dub file. Did you clone with the submodules 
(requiring sub modules is not ok for dub just an FYI)?

[Issue 18882] __gshared not displaying in debuginfo

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Manu  ---
Hmm... yeah, that's unfortunate.

I don't understand why it's hard to resolve the name. It's extern(C++), and it
has no namespace supplied, so the correct symbol name should just be the
mangled name, with no scope or anything.

How is it that qualified names (with the D scope) can find a C++ symbol? The
C++ symbol has no concept of D scope. Why does it need to be given a scope at
all?

--

[Issue 18879] !is doesn't highlight correctly

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Rainer Schuetze  ---
The distinction matters if keywords and operators are supposed to show
different colors.

--

Re: Reserved 1.0.0

[Fra Mecca via Digitalmars-d-announce]

On Wednesday, 16 May 2018 at 08:38:05 UTC, Andrea Fontana wrote:
I released another small library on behalf of the company I 
work for (http://lab.2night.it). It is called "reserved", and 
it's a small library you can use to run your D webpages/service.


It is focused on simplicity (no dependencies) and fast setup. 
It use scgi to interface itself with nginx/apache/etc through 
unix sockets.


More info: http://code.dlang.org/packages/reserved

Comments are welcome.

Andrea Fontana


Ciao Andrea,
it is very nice to see an italian company (being an italian 
myself) publishing in the forum and using D.

Thanks for the contribution.

Francesco

Examples/tutorials for OpenGL games which works out-of-the-box on linux

[Prokop Hapala via Digitalmars-d-learn]

Hi,

I'm looking for examples of OpenGL games which I can use as 
templates for making my own stuff. But I'm quite discouraged that 
everything I found on github is probably outdated and fails to 
compile. Since I'm not very familiar with dub environment I don't 
feel able to correct the errors in dependences etc.


e.g.:

* https://github.com/Circular-Studios/Dash (depends on old 
version of vibe.d, when update the  dub.json it gives this error:
source/dash/components/mesh.d(8,19): Error: module `stream` is in 
file 'std/stream.d' which cannot be read


* https://github.com/d-gamedev-team/opengl-tutorials - depends on 
some libs like `glad-drey,glfw-drey,glwtf-dray` which are perhaps 
old versions of Derelict bindings, but I won't try to set it up


* https://github.com/Extrawurst/unecht - There is no setup/build 
readme, when I just hit `dub run` I get errors about missing parts
No package file found in 
/home/prokop/git_SW/_Dlang/unecht/submodules/tharsis.prof/, 
expected one of dub.json/dub.sdl/package.json

[Issue 18882] __gshared not displaying in debuginfo

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Rainer Schuetze  ---
See also issue 11024: there is no information about imports in the debug
informations so you don't know which symbols are visible in the current scope
and what their qualified name is.

In D functions, the qualified name is used to find the requested symbol, too.
This fails for extern(C/C++) functions that don't have the qualification, or if
the symbol is in another module.

You can still watch the variable using the fully qualified name (even for
extern(C++) symbols), e.g. "dmd.globals.global". This actually matches C++
symbols that are in namespaces which also have to be specified.

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Manu  ---
Even if we can't see the symbol names, seeing the pointers might help matching
values and confirm function order against C++ code that you can also see in the
debugger.

--

[Issue 18879] !is doesn't highlight correctly

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Manu  ---
Oh? I didn't know they did... they're all blue by default on my setup :)

--

Re: C style callbacks fix for member callbacks

[MGW via Digitalmars-d-learn]

On Saturday, 19 May 2018 at 23:52:58 UTC, IntegratedDimensions 
wrote:

I have a member callback that I want to use as a C callback.



http://www.agner.org/optimize/calling_conventions.pdf

https://www.youtube.com/watch?v=xhDS377mAc4

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from Rainer Schuetze  ---
The build was ok, I just looked at the class instance before it was
initialized.

I've now added symbol names (no demangling yet). One gotcha: if you are linking
with /INCREMENTAL, the linker relocates symbols through a series of jumps and
that confuses the symbol display.

--

Mysql query result access by field name

[ipkwena via Digitalmars-d-learn]

I have started learning D and I am enjoying it so far.

How does one access the columns fields in a Mysql query results 
by the column name. Currently I have to use the method as shown 
in a couple of example by indexing array values (f being a struct 
variable):


Data f;
f.name = to!string(allrows[0][0]);
f.surname = to!string(allrows[0][1]);
f.title  = to!string(allrows[0][2]);

I am using the mysql-native package or DB connectivity.

Regards

Re: C style callbacks fix for member callbacks

[IntegratedDimensions via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 08:40:57 UTC, MGW wrote:
On Saturday, 19 May 2018 at 23:52:58 UTC, IntegratedDimensions 
wrote:

I have a member callback that I want to use as a C callback.



http://www.agner.org/optimize/calling_conventions.pdf

https://www.youtube.com/watch?v=xhDS377mAc4


Sorry, I can't understand Russian(wish I could!). It also does 
not seem applicable for my problem. Although It is a useful idea 
here(using D in C++).


alias callback = extern(C) int function(const(void) a, void *b, 
uint c, void* context);


Where context acts as this.

I would like to assign a D method to this callback.

class
{
   callback c;
   /*extern(C) static*/ int foo(const(void) a, void *b, uint c, 
void* context);

   this() { c = cast(callback) }
}

http://asm.dlang.org/ needs updating

[IntegratedDimensions via Digitalmars-d]

load and save are not working, an example is always compiled in. 
No code in the input box still shows examples code in the 
disassembly.

[Issue 1578] Allow AA literals to initialize static variables

[d-bugmail--- via Digitalmars-d-bugs]

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

Ethan Watson  changed:

   What|Removed |Added

 CC||goober...@gmail.com

--- Comment #4 from Ethan Watson  ---
Came here from issue 6238

10.5 years and this is still a problem. Encountered when trying to assign AA
literal to a struct member.

See https://run.dlang.io/is/BDVjxP for another example.

--

Re: Help with DMD internals

[Manu via Digitalmars-d]

On 20 May 2018 at 12:28, Manu  wrote:
>
> [...]

Then... next up, extern(C++) classes need to place __xdtor in the
vtable (posix uses 2 slots).
We need the vtable to match naturally, without advising people to add
a dummy method.

I also have a hack in progress to support `final ~this()` in
extern(C++) classes, which will omit it from the vtable (once it's in
there!), since there are also C++ classes without virtual destructors.

This work is hard... adding the dtor to the vtable freaks DMD out in
all sorts of ways and ICE's everywhere.


Any comments on any of these points appreciated. I don't know what I
don't know. There's probably reasons that these things aren't all done
already...

Re: auto: useful, annoying or bad practice?

[Neia Neutuladh via Digitalmars-d]

On Sunday, 20 May 2018 at 14:35:21 UTC, I love Ice Cream wrote:

On Sunday, 20 May 2018 at 02:34:38 UTC, Neia Neutuladh wrote:
D is very hard to make an IDE for that would actually tell you 
what type the return value is.


This might sound a little hard, but that's probably a 
fundamental failure of the D language and explains some of the 
poor tooling around the language.


This is specifically when metaprogramming is going on.

Most programming languages these days fall into one of three 
categories:


* They don't support metaprogramming.
* They support metaprogramming by reflection only, like Java and 
Go. As soon as you use any metaprogramming, your IDE can't tell 
you what types things are; you've got interface{} or Object and 
you're calling Field.get() and Method.invoke().
* They support metaprogramming by merit of being a dynamic 
language. As soon as you write a line of code, your IDE can't 
tell you what types things are.


If you write D without any metaprogramming, it's as easy to write 
an IDE for that as for Java.


The problem is that metaprogramming is useful, and in D it's not 
that hard, so we use it a lot. There are proposals floating 
around for "concepts" or "signatures" (basically, compile-time 
interfaces) that would help out a lot, but nobody's driven one of 
those proposals to completion, as far as I know.

Re: http://asm.dlang.org/ needs updating

[Walter Bright via Digitalmars-d]

On 5/20/2018 9:47 AM, IntegratedDimensions wrote:
load and save are not working, an example is always compiled in. No code in the 
input box still shows examples code in the disassembly.


Please post bug reports to https://issues.dlang.org/

Re: Convert mixin to function call

[IntegratedDimensions via Digitalmars-d-learn]

https://dpaste.dzfl.pl/fb49bf834cff

import std.stdio;

auto Q(string A)()
{
auto foo()
{
auto d = mixin(Z!(A)());
return d;
}
return foo()();
}

auto X(string A, string N)()
{
return N~" = (() { int y = 4;  return "~A~" + y + 5; })();";
}

auto Z(string A)()
{
return "() { int y = 4;  return "~A~" + y + 5; }";
}


void main()
{
int x = 3;
double y = 0;
pragma(msg, (X!("x", "y")()));
mixin(X!("x", "y")());
y = Q!("x")();

writeln(y);
}

using Q is more ideomatic but foo does not have access to x which 
is required(since Q should behave like a string mixin as far as 
scope is concerned).

[Issue 18879] !is doesn't highlight correctly

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Rainer Schuetze  ---
Actually never implemented in the "new" parser that is now used for about 5
years. I've added it now and preview should be available in a couple of minutes
here: https://ci.appveyor.com/project/rainers/visuald

--

Re: Found on proggit: simple treap language benchmark, includes D

[Nerve via Digitalmars-d]

On Saturday, 19 May 2018 at 15:09:38 UTC, Joakim wrote:

D does well, comes in second on Mac/Win/linux:

https://github.com/frol/completely-unscientific-benchmarks
https://www.reddit.com/r/programming/comments/8jbfa7/naive_benchmark_treap_implementation_of_c_rust/


The results in these tests are blazing fast, but they all forego 
the GC for manual allocation.


In the Issues section of the repo, I included some simple, 
vanilla D translated from their Java implementation and made for 
use with the GC and runtime. I also included some raw sample 
times that are competitive with desktop i7 times of Rust and 
ref-counted C++ on...get this...a much slower laptop i5.


This sort of thing needs to be shouted from the rooftops by the 
Foundation.


I'll see if I can get it included so they can test it on their 
specific setup.

[Issue 18886] New: Explicitly invoking super.__ctor in a constructor does not count as calling a super constructor

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18886
   Summary: Explicitly invoking super.__ctor in a constructor does
not count as calling a super constructor
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: goober...@gmail.com

Example code at https://run.dlang.io/is/Is9tAs

A workaround is to define a default constructor, as per
https://run.dlang.io/is/mhM24Y

But this is just doubling up on work that I shouldn't need to do.

Came about because I was trying to explicitly invoke a templated constructor in
a base class. Simple example at https://run.dlang.io/is/XAsoyo

--

Re: auto & class members

[Robert M. Münch via Digitalmars-d-learn]

On 2018-05-20 14:49:59 +, Jonathan M Davis said:


In cases like this, typeof is your friend. e.g. something like

typeof(myStream.filter!(a => a == myMessage)) mySubStream;


Hi Jonathan, great! This got me a step further. So I can declare my 
member now. But I get an implict cast error when I try:


class a {
... myStream;
}

class b {
typeof(a.myStream.filter!(x => x == myMessage)) mySubStream;
}

void myFunc() {
a myA = new a();
b myB = new b();

myB.mySubstream = myA.myStream.filter!(x => x == myMessage);
}

This gives (unnecessary stuff stripped):

Error: cannot implicitly convert expression filter(...) of type 
app.myFunc.filter!(x => x == myMessage) to app.b.filter!(x => x == 
myMessage)


Why is myFunc now entering the game? I mean it's just the function 
containing the code. It seems that:


typeof(myA.myStream.filter!(x => x == myMessage))

and

typeof(a.myStream.filter!(x => x == myMessage)) are not the same.

But inside class b I can't use a specific variable instance. And in 
myFunc, I can't use a class type but need the specific instance.


Any further idea?



though you might have trouble with the lambda being subtly different type
even if you replace myMessage in it with something that will work in the
scope that mySubStream is being declared.


Not sure if the above problem is exactly what you mention here. This is 
all pretty tricky.




However, that could be fixed by
doing something like replacing the lambda with a free function or just
creating a function that returns what you want to assign to mySubStream.
Then you could just do something like

typeof(myHelperFunc(myStream)) mySubStream;

The exact solution can get a bit annoying in cases like this (it's arguably
the biggest downside to auto returns), but typeof does provide a way out if
you can get the expression to it to work. It is easier with local variables
than member variables though, since you don't necessarily have everything
you want to use in the expression that will give the variable its value
available at the point that the variable is declared - but that's why
a helper function can help, since it provides a way to encapsulate the
expression and reuse it between the assignment and the declaration.


Not sure I understand every aspect but it's getting clearer... Thanks so far.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

[Issue 18234] [REG 2.075] Case of link failure when a program is compiled against a static lib

[d-bugmail--- via Digitalmars-d-bugs]

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

David Nadlinger  changed:

   What|Removed |Added

 CC||c...@klickverbot.at

--- Comment #1 from David Nadlinger  ---
(In reply to Basile B. from comment #0)
> > digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is untestable.
> > digger: There are only untestable commits left to bisect.
> > digger: The first bad commit could be any of:
> > digger: 1e7b526b40852e9b85df3684430e371034cdf7ec
> > digger: 6fecaa8232a427fb3ca29c5a5245e08fc43b71b1
> > digger: f0410bea1ad2b130884964d603b34e729b3e4f69
> > object.Exception@bisect.d(186): We cannot bisect more!
> 
> However they don't seem to exist.

These hashes refer to the commits in Vladimir's top-level repo that combines
commits to the various compiler and runtime repositories into one linear
history: https://bitbucket.org/cybershadow/d

Unfortunately, the corresponding commits are big master -> stable merges, which
is not very helpful:

https://github.com/dlang/dmd/pull/6915
https://github.com/dlang/phobos/pull/5491
https://github.com/dlang/druntime/pull/1841

--

[Issue 18879] !is doesn't highlight correctly

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from Manu  ---
Added distinct colour, or fixes for !is/!in? :)

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Manu  ---
Haha, oh man. Everything is always so hard! ;)

I turned it off and everything works great!

Sadly, /INCREMENTAL is overwhelmingly common, and also the default... basically
nobody will ever turn that off :/

--

Convert mixin to function call

[IntegratedDimensions via Digitalmars-d-learn]

I have a string mixin that returns a value or function that uses 
the mixed in scope.


Currently I have to wrap the mixin in a delegate or local 
function as to be able to get the value:


int x = 3;
int y = 1;
auto foo() { mixin(X!("x")); }

This allows the the mixin to see the scope but keep the mixin 
variables local so they do not shadow anything unintentionally.


auto X(string A)()
{
return "int y = 4; return "~A~" + y + 5;";
}

foo will just return 8 but I cannot simply mixin within the main 
scope or the scope will return unintentionally.


int x = 3;
mixin(X!("x")) // <- hidden return


Using foo works fine but adds a level of indirection I feel is 
unnecessary. The only thing I feel can work is to rewrite X so 
that it uses variables with random names to reduce shadowing 
issues and to allow X to take a variable name to put the result 
in:


auto X(string A, string N)()
{
return "{ int _342sdfs = 4;  "~N~" = "~A~" + _342sdfs + 5;}";
}

which complicates things significantly. My hope is that D would 
inline the function call.


Ideally I'd like to be able to sort of use the mixin as a 
function and simply call it:



val = mixin(X!("x"))();

which I could do by internally using a delegate inside the mixin


auto X(string A)()
{
return "(() { int y = 4; return "~A~" + y + 5; })";
}

except that the mixin syntax does not allow one to use it in an 
expression.


Remember that the mixin must be able to see the scope it is mixed 
in at so one can't wrap this in a template use it as far as I 
know?


Although, one can do

mixin(X!("val", "x"));

which does the ugly work.

It would be nice to be able to get this process to look as much 
like normal D code as possible.


the idea is to try to write "local" string mixins that are messy 
and not "C'ish" looking in to "C'ish" looking code.

Re: Convert mixin to function call

[IntegratedDimensions via Digitalmars-d-learn]

Also, one thing that would help would be able to create 
identifier names that are unique to avoid collisions. Does D have 
any ability to do such a thing?

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from Manu  ---
I just noticed a minor issue...

Mago is displaying hex with A-F in CAPS.
VS debugger displays hex with a-f in lower case.

I'm finding it surprisingly jarring when calling in/out of D, because a pointer
that I was just looking at *looks* different, and I think the value has
changed.
Can we make Mago match VS with lower case hex?

--

[Issue 18887] inout badly described

[d-bugmail--- via Digitalmars-d-bugs]

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

Bolpat  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All
   Severity|enhancement |normal

--

[Issue 18887] New: inout badly described

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18887
   Summary: inout badly described
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: qs.il.paperi...@gmail.com

On the page Type Qualifiers[1] "inout" is not being described at any point.
It's absolutely confusing for newcommers (apart from "inout" not being related
to "in" and "out" storage classes).

[1] https://dlang.org/spec/const3.html

--

[Issue 18846] VisualD - show vtable in debugger

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #9 from Manu  ---
Also, another super-minor detail.
In C++, it shows the derived type member at the top, then __vfptr (ie, first
member), then the normal member listing.

In Mago, it's showing __vfptr at the top, then the derived type member, then
the normal members.
Can we swap those top 2 items to match C++? __vfptr is really just the first
member, and it feels strange when it's disconnected from the other members
(separated by the derived accessor) that way.

--

Re: Help with DMD internals

[Walter Bright via Digitalmars-d]

On 5/20/2018 12:28 PM, Manu wrote:

I've started digging at some surfac-ey extern(C++) issues.


I've improved the definition of how construction works, such as when the .init 
happens, in the spec.


https://dlang.org/spec/class.html#constructors

> Is __xdtor **always** present?

No. If it's POD, it is not. When it is added, it is added as an 
AliasDeclaration, not a FuncDeclaration. See buildDtor() in clone.d, which is 
where it is created.


You can also see in that function how _ArrayDtor and __fieldDtor are built on 
demand, and the order in which they are called.

Re: Convert mixin to function call

[IntegratedDimensions via Digitalmars-d-learn]

It should be obvious that these are simplifications. I can't pass 
the variables directly as parameters as in the real case the 
names may only be partially specified.

[Issue 18884] getSymbolsByUDA fails on AliasSeq members

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #1 from Simen Kjaeraas  ---
PR:
https://github.com/dlang/phobos/pull/6518

--

Re: GDC Explorer - an online disassembler for D

[IntegratedDimensions via Digitalmars-d]

On Friday, 21 September 2012 at 03:46:12 UTC, Andrei Alexandrescu 
wrote:
I've met Matt Goldbolt, the author of the GCC Explorer at 
http://gcc.godbolt.org - a very handy online disassembler for 
GCC.


We got to talk a bit about D and he hacked together support for 
D by using gdc. Take a look at http://d.godbolt.org, I think 
it's pretty darn cool! I'm talking to him about integrating his 
work with our servers.



Andrei


Compare a simple C++ to D and the C++ output is far better:

class C
{
int x = 12;
public:
int foo(int y) { return y*x; }
};

int main()
{
   C* c = new C();
   return c->foo(2);
}



VS




class C
{
int x = 12;
public:
int foo(int y) { return y*x; }
};

int main()
{
   C c = new C();
   return c.foo(2);
}








operator new(unsigned long)@plt:
 jmpQWORD PTR [rip+0x200baa]# 601020 new(unsigned long)@GLIBCXX_3.4>

 push   0x1
 jmp400450 <.plt>
main:
 push   rbp
 movrbp,rsp
 push   rbx
 subrsp,0x18
 movedi,0x4
 call   400470 
 movrbx,rax
 movDWORD PTR [rbx],0x0
 movrdi,rbx
 call   4005bc 
 movQWORD PTR [rbp-0x18],rbx
 movrax,QWORD PTR [rbp-0x18]
 movesi,0x2
 movrdi,rax
 call   4005a4 
 nop
 addrsp,0x18
 poprbx
 poprbp
 ret
 nop
C::foo(int):
 push   rbp
 movrbp,rsp
 movQWORD PTR [rbp-0x8],rdi
 movDWORD PTR [rbp-0xc],esi
 movrax,QWORD PTR [rbp-0x8]
 moveax,DWORD PTR [rax]
 imul   eax,DWORD PTR [rbp-0xc]
 poprbp
 ret
 nop
C::C():
 push   rbp
 movrbp,rsp
 movQWORD PTR [rbp-0x8],rdi
 movrax,QWORD PTR [rbp-0x8]
 movDWORD PTR [rax],0xc
 nop
 poprbp
 ret
 nopWORD PTR cs:[rax+rax*1+0x0]
 nopDWORD PTR [rax+rax*1+0x0]




VS










_Dmain:
 push   rbp
 movrbp,rsp
 subrsp,0x10
 movrdi,QWORD PTR [rip+0x0]# f <_Dmain+0xf>
 call   14 <_Dmain+0x14>
 movQWORD PTR [rbp-0x8],rax
 movesi,0x2
 movrdi,rax
 movrax,QWORD PTR [rax]
 rex.W call QWORD PTR [rax+0x28]
 leave
 ret
 addBYTE PTR [rax],al
main:
 push   rbp
 movrbp,rsp
 subrsp,0x10
 movDWORD PTR [rbp-0x10],edi
 movQWORD PTR [rbp-0x8],rsi
 movrdx,QWORD PTR [rip+0x0]# 16 
 movrsi,QWORD PTR [rbp-0x8]
 movedi,DWORD PTR [rbp-0x10]
 call   22 
 leave
 ret
.text.d_dso_init:
 push   rbp
 movrbp,rsp
 learax,[rip+0x0]# b <.text.d_dso_init+0xb>
 push   rax
 learax,[rip+0x0]# 13 <.text.d_dso_init+0x13>
 push   rax
 learax,[rip+0x0]# 1b <.text.d_dso_init+0x1b>
 push   rax
 push   0x1
 movrdi,rsp
 call   26 <.text.d_dso_init+0x26>
 leave
 ret


the C++ version is more verbose, gives explicit references to 
functions and methods while the D version requires you to hunt 
and peck.

Re: auto & class members

[Robert M. Münch via Digitalmars-d-learn]

On 2018-05-20 17:40:39 +, Robert M. Münch said:

Hi Jonathan, great! This got me a step further. So I can declare my 
member now. But I get an implict cast error when I try:


class a {
... myStream;
}

class b {
typeof(a.myStream.filter!(x => x == myMessage)) mySubStream;
}

void myFunc() {
a myA = new a();
b myB = new b();

myB.mySubstream = myA.myStream.filter!(x => x == myMessage);
}

This gives (unnecessary stuff stripped):

Error: cannot implicitly convert expression filter(...) of type 
app.myFunc.filter!(x => x == myMessage) to app.b.filter!(x => x == 
myMessage)


Answering myself: Using an alias helps.

alias typeof(a.myStream.filter!(x => x == myMessage)) myMessageType;

class b {
myMessageType mySubStream;
}

void myFunc() {
a myA = new a();
b myB = new b();

	myB.mySubstream = cast(myMessageType)myA.myStream.filter!(x => x == 
myMessage);

}

But I still don't understand why I can't write things explicitly but 
have to use an alias for this.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Help with DMD internals

[Manu via Digitalmars-d]

I've started digging at some surfac-ey extern(C++) issues.

First up, I desperately want a document that describes D's precise
construction/destruction rules; there are a bunch of generated
functions, they get called, in what order, and under what conditions?

Construction:
  What is the order of operations?
  Where and when is init applied before calling constructors?
  What about super-constructors? Aggregate member constructors? When
are where-from are they called?
  Is this all wrapped in an outer '__xctor' function that does the
whole job? Is it all rolled into __ctor? Or is it just a bunch of
loose operations that appear at the call-site?
  I want a function that wraps initialisation, super construction,
aggregate construction, and local construction; similar to __xdtor is
for destruction. That function would match C++, and that would be the
logical point of interaction with C++ (mangling).

Destruction:
  What's the precise story with __dtor, __xdtor, __fieldDtor?
  Is __xdtor **always** present?
  extern(C++) seems to have bugs(?) with __xdtor...
  Is re-initialisation to 'init' part of destruction, or is it a
separate post-process? (I feel it's a post-process)


Regarding extern(C++), I've started with trying to mangle correctly,
but then next will come trying to match C++ semantics.

Issue 1: extern(C++) classes have broken __xdtor. I observe
extern(C++) classes with no destructor will generate an __xdtor that
correctly calls aggregate destruction. If you then add a destructor
(__dtor), __xdtor will call that function directly (or maybe it just
becomes an alias?), and aggregate destruction will no longer occur.

Issue 2: assuming the above is fixed, __xdtor matches C++ expectation
for destruction. I intend to change the mangling such that __xdtor
mangles as the C++ symbol, and not __dtor.

Issue 3: If the user specifies an extern(C++) destructor *prototype*
with no implementation (ie, extern link to C++ destructor), it needs a
hack to re-interpret as a prototype for an extern __xdtor, rather than
__dtor (and __dtor can happily not exist, or just alias). C++
destructors perform a full-destruction, which is equivalent to __xdtor
from D's perspective.

That should lead to destruction semantics matching C++.


Matching construction semantics is a little bit fiddly too. It might
need special-casing.
D doesn't seem to wrap up a full construction into a single nice
function like C++ does... or does it? I'm struggling to understand D
construction from end-to-end.


Let's not talk about passing by-val... yet.

[Issue 18819] DMD compilation crash

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #4 from ag0aep6g  ---
(In reply to Mike Franklin from comment #3)
> I can reproduce this at run.dlang.io, but I can't reproduce it locally from
> DMD-Head (Linux 64-bit).

I can reproduce it just fine on Linux with DMD64 D Compiler
v2.080.0-166-g235e5b500 (i.e. git master).

Crashes with:

core.exception.AssertError@dmd/dinterpret.d(4834): Assertion failure

That's here:
.

Also, reduced test case:


struct Problem
{
~this() {}
}
struct S
{
Problem[1] payload;
}
enum theTemplateB = {
static foreach (e; S.init.tupleof) {}
return true;
}();


--

[Issue 18234] [REG 2.075] Case of link failure when a program is compiled against a static lib

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Basile B.  ---
There's some progress, using -allinst solves the problem

---
if [ ! -d "iz" ]; then
git clone https://www.github.com/BBasile/iz.git
fi

cd iz
git checkout v0.6.4
cd scripts
sh compile.sh
cd ../
dmd samples/dictionnary_suffixarray.d lib/iz.a -Iimport -allinst
---

giving a hint on what the exact problem is i hope.

--

[Issue 18888] New: extern(C++) template arg/alias arg mangling issue

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 1
   Summary: extern(C++) template arg/alias arg mangling issue
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

This C++ code:
--
template 
struct TemplateName
{
void fun() {}
};

template