Why's that? Shouldn't _all_ 0 size variables compare equal? I'd
say that follows from the definition:
array1 == array2
=
all corresponding elements of both arrays are equal
=
no corresponding elements of both arrays are different
For the last one, it's obvious that
On Wednesday, 3 June 2015 at 01:57:21 UTC, bitwise wrote:
'in' is currently useless because scope is not defined
properly, and const is too restrictive. Also, because of DIP25,
it's now even more useless. It seems a pretty sure bet that it
will either continue to be completely useless or be
On Tuesday, 9 June 2015 at 17:15:46 UTC, Dennis Ritchie wrote:
On Tuesday, 9 June 2015 at 17:12:53 UTC, Liam McSherry wrote:
I think containers would be the better option. D sorely needs
to have basics like (de)queues and stacks in the standard
library, as well as any other popular and useful
On Tuesday, 9 June 2015 at 17:38:00 UTC, Steven Schveighoffer
wrote:
But passing a large rvalue by value does not involve any moving
of data, and can be abstracted to a pass by ref if needed. It's
never less performing than an explicit pass by ref.
Thanks Steve.
The problem I see here on
On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
And I still think Timon's statement is untrue. There is a
reason, which is that the new auto ref syntax forces reference
parameters for all types(even primitives), where the old
template approach does not.
Timon suggested using another
On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote:
On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr
timon.g...@gmx.ch wrote:
There is no reason to prevent templates from using the
mechanism that generates only one copy. The two mechanisms
shouldn't share the same syntax, because then
On Monday, 22 June 2015 at 23:04:14 UTC, Timon Gehr wrote:
On 06/23/2015 12:18 AM, kinke wrote:
In C++ there's no problem with const, so why they will be
in D?
Because const is transitive in D and therefore more
restrictive.
That's not a reason.
Yes it is.
It's just an additional
On Monday, 22 June 2015 at 18:34:37 UTC, Namespace wrote:
On Monday, 22 June 2015 at 18:03:43 UTC, Temtaime wrote:
I see no reasons why « ref in » is bad. Maybe someone explain ?
It's also natural for those who came from C++.
In C++ there's no problem with const, so why they will be in
D?
On Monday, 22 June 2015 at 16:54:50 UTC, Marc Schütz wrote:
On Monday, 22 June 2015 at 16:10:10 UTC, Namespace wrote:
Rather than raising the matter of scope again and again, we
should be thankful that a solution for this nasty problem is
accepted and could be merged.
I disagree strongly
On Saturday, 20 June 2015 at 20:43:21 UTC, Nick Sabalausky wrote:
On 06/20/2015 05:27 AM, Vladimir Panteleev wrote:
[...]
+1kazillion
+1 ;)
On Saturday, 27 June 2015 at 11:10:49 UTC, Marc Schütz wrote:
On Saturday, 27 June 2015 at 01:18:19 UTC, Jonathan M Davis
wrote:
That's a completely orthogonal issue to ref or auto ref.
That's an @system operation (since taking the address of a
local variable is @system), and it's up to you to
On Thursday, 25 June 2015 at 10:10:42 UTC, Jonathan M Davis wrote:
Whether a reference escapes is an orthogonal issue. The return
attribute is for dealing with that. The function should be able
to return by ref or not and still accept both rvalues and
lvalues for its parameters. As long as the
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array; }
int start() @property { printf(start()\n); return 0; }
int end() @property { printf(end()\n); return 1; }
void main()
{
array[start..end] = 666;
On Sunday, 24 May 2015 at 19:48:05 UTC, Jonathan M Davis wrote:
The original code is clearly wrong. And forcing the order of
evaluation so that it's one way or the other just changes under
which cases you end up with bugs. Mutating in an expression
while using it multiple times in that
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote:
It might be completely well-defined and consistent, but it may
not be what you expect, and even if it is, a slight change to
the code could change the order.
If the behavior isn't what I expect (and I don't think that's
often
On Monday, 25 May 2015 at 17:21:05 UTC, Johannes Pfau wrote:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
So what about my previous example?
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote:
If the litmus test is What does GDC do?, then LDC is doing
it the correct way. :-)
Perfect. :)
On Monday, 25 May 2015 at 19:17:48 UTC, Timon Gehr wrote:
Even if it isn't. ;)
It is - on its merge-2.067 branch. ;)
On Thursday, 13 August 2015 at 17:56:06 UTC, tcak wrote:
On Thursday, 13 August 2015 at 16:44:09 UTC, David Nadlinger
wrote:
On Thursday, 13 August 2015 at 16:30:59 UTC, learn wrote:
On Thursday, 13 August 2015 at 11:04:21 UTC, Rikki Cattermole
wrote:
It was posted there.
It's a known issue.
The following snippet is interesting:
<<<
__gshared int step = 0;
__gshared int[] globalArray;
ref int[] getBase()
{
assert(step == 0);
++step;
return globalArray;
}
int getLowerBound(size_t dollar)
{
assert(step == 1);
++step;
assert(dollar == 0);
globalArray = [
Ping. Let's clearly define these hairy evaluation order details
and add corresponding tests; that'd be another advantage over C++.
On Sunday, 26 June 2016 at 08:08:58 UTC, Iain Buclaw wrote:
Now when creating temporaries of references, the reference is
stabilized instead.
New codegen:
*(_ptr = getBase());
_lwr = getLowerBound(_ptr.length);
_upr = getUpperBound(_ptr.length);
r = {.length=(_upr - _lwr), .ptr=_ptr.ptr +
On Monday, 18 January 2016 at 17:48:39 UTC, Namespace wrote:
You don't give up, huh? ;)
I'm glad he doesn't. I couldn't agree more with Manu. It's the
one thing I really, I mean *really* detest about D.
To me, this rvalue-to-ref bindability is 100x more important than
the GC. Yet it keeps on
On Saturday, 20 February 2016 at 00:25:12 UTC, Martin Krejcirik
wrote:
How do I run DMD tests on Windows ? I'm not able to, even with
gmake.
You may want to have a look at
http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC#Running_the_dmd-testsuite_tests for some tools
On Sunday, 21 February 2016 at 16:45:14 UTC, Martin Krejcirik
wrote:
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
--- errorlevel 1104
Stock dmd doesn't require libucrt.lib. If I copy it to
dmd2\windows\lib64 a get:
D:\devel\bugs>dmd -m64 utfbug
DMD v2.068 DEBUG
On Friday, 4 March 2016 at 17:49:09 UTC, John Colvin wrote:
Surely after inlining (I mean real inlining, not dmd) it makes
no difference, a constant is a constant?
I remember doing tests of things like that and finding that not
only did it not make a difference to performance, ldc produced
On Friday, 4 March 2016 at 20:14:41 UTC, Andrei Alexandrescu
wrote:
This is just speculation. When the stride is passed to larger
functions the value of the stride is long lost.
I understand the desire for nice and simple code but sadly the
stdlib is not a good place for it - everything must
On Wednesday, 13 July 2016 at 21:06:28 UTC, kinke wrote:
On Monday, 27 June 2016 at 02:38:22 UTC, Timon Gehr wrote:
The point is that the slice expression itself does or does not
see the updates based on whether I wrap base in a lambda or
not.
I don't really see a necessity for the lambda to
On Monday, 27 June 2016 at 02:38:22 UTC, Timon Gehr wrote:
As far as I understand, for the first expression, code gen will
generate a reference to a temporary copy of base, and for the
second expression, it will generate a reference to base
directly. If lwr() or upr() then update the ptr
I was wondering whether C++ interop is already considered
sufficiently working enough, as I don't see any plans for
improving it in the H1 2017 vision, except for the `C++ stdlib
interface` bullet point.
IMO, the main obstacles for mixed D/C++ RAII-style code are:
1) Constructors don't work
On Monday, 30 January 2017 at 19:05:33 UTC, Q. Schroll wrote:
Can't we make "in" mean "const scope ref", that binds on
r-values, too? Effectively, that's (similar to) what "const T&"
in C++ means. It's a non-copying const view on the object. We
have the longstanding problem, one must overload
Side note: Microsoft uses a different C++ mangling...
On Tuesday, 14 February 2017 at 14:11:31 UTC, Sönke Ludwig wrote:
It's a quite frequent issue to get unresolved externals on
Windows, because the lib files of the Windows platform SDK are
still stuck at Windows XP age. It would make a lot of sense to
update those to the latest Windows 10 SDK,
On Tuesday, 14 February 2017 at 20:03:13 UTC, Jonathan M Davis
wrote:
That being said, at some point, you have to ask whether each
added feature is worth the cost when you consider how it's
going to clutter up function signatures even further. And while
I do think that there is value in DIP
On Wednesday, 24 August 2016 at 21:13:45 UTC, Guillaume Piolat
wrote:
A minor problem is that on Windows users expect both x86 and
x86_64 builds so one has to juggle with the 2 LDC PATH to
release both. I've said this thrice already and it's quite
minor really.
There's a multilib edition for
On Thursday, 6 October 2016 at 20:55:55 UTC, Ilya Yaroshenko
wrote:
So, I don't see a reason why this change break something, hehe
No, Iain is right. These LLVM intrinsics are most often simple
forwarders to the C runtime functions; I was rather negatively
surprised to find out a while ago.
On Thursday, 22 September 2016 at 17:09:38 UTC, Brian wrote:
I use cygwin build a C++ lib file:
libmemcached.a
but, how to link it to my dub project?
You'd probably need to use the GNU linker then, but the D objects
would need to match the format used for your C++ lib. You could
give the
I found it hard to believe LDC generates such crappy code when
optimizing. These are my results using LDC master on Win64 (`ldc2
-O -release -output-s`):
struct Foo
{
immutable _u = 8;
int foo() const
{
return 8 * _u;
}
}
int use(ref const(Foo) foo)
{
return
On Thursday, 25 August 2016 at 18:09:14 UTC, Cecil Ward wrote:
On Thursday, 25 August 2016 at 18:07:14 UTC, Cecil Ward wrote:
On Thursday, 25 August 2016 at 17:22:27 UTC, kinke wrote:
[...]
I think that here the optimisation is only because LDC can
“see” the text of the method. When
On Thursday, 25 August 2016 at 18:15:47 UTC, Basile B. wrote:
The problem here that the example is bad with too agressive
optimizations because the CALLs are eliminated despite of no
inlining.
[...]
int use(const(Foo) foo)
{
return foo.foo() + foo.foo();
}
From my perspective, the
On Tuesday, 28 March 2017 at 02:14:25 UTC, Jonathan M Davis wrote:
Realistically, unless D fully supports C++ (which pretty much
means that it has to become C++ on some level), you're almost
always going to be stuck with some sort of glue layer between D
code and C++ code. There's no
On Tuesday, 28 March 2017 at 12:55:02 UTC, deadalnix wrote:
On Tuesday, 28 March 2017 at 08:30:43 UTC, kinke wrote:
What I don't get is why it's considered important to have a
matching C++ mangling for templates across D and C++ - what
for? I only care about mangling wrt.
If you still think
On Tuesday, 28 March 2017 at 14:11:16 UTC, deadalnix wrote:
I understand you point and showed you why it isn't a mangling
problem at all, and gave you direction you may want to dig in
to make a proposal that may
actually get traction.
If you really did get my point, it should be clear that I
On Sunday, 26 March 2017 at 17:41:57 UTC, Benjamin Thaut wrote:
There are thousands of C++ libraries out there that can't be
bound to D because they use const Class* instead of const
Class* const. So in my eyes there is definitly something wrong
with the C++ mangling of D.
I agree that
On Monday, 27 March 2017 at 20:09:35 UTC, Walter Bright wrote:
Whichever way it is mangled will gore someone's ox. D went with
the simplest mangling solution, which is to mangle all C++
const pointers as "head const".
[...]
I suggest a simpler way - declare the C++ side of the D
interface in
On Monday, 27 March 2017 at 22:04:55 UTC, Walter Bright wrote:
On 3/27/2017 1:41 PM, kinke wrote:
Unfortunately, it's almost always the other way around - D
code trying to
interop with one of the gazillions existing C++ libs, and
nobody wants to
maintain his own fork with D-compatible glue
On Monday, 27 March 2017 at 22:24:26 UTC, Walter Bright wrote:
On 3/27/2017 3:12 PM, kinke wrote:
It's made to work with:
const T
which is the norm with C++ templates.
Okay, so how exactly do I bind D code to a C++
header-only-template library? I
thought that in that case you need a
On Monday, 20 March 2017 at 12:44:32 UTC, Laeeth Isharc wrote:
becoming more involved in the Chinese open-source community
I thought we had left behind nations and borders in the
open-source community. - Sorry, I couldn't resist. ;)
On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:
D is currently built and optimized for that dying PC platform.
I don't think x86 is dying soon, but I agree that embedded
architectures get more important every day and should get more
focus.
I would even go so far as to say it may
I'm slightly annoyed by DPaste providing a single ancient LDC
version (0.12, 2.063 front-end...). I wouldn't mind as long as it
wouldn't boldly state `We provide always up-to-date compilers
collection!` and it wasn't the first result when googling for
"dlang online compiler" (I prefer
On Tuesday, 7 March 2017 at 18:46:15 UTC, Johan Engelen wrote:
On Tuesday, 7 March 2017 at 18:42:40 UTC, Johan Engelen wrote:
It works on OS X too.
And OS X is the only platform for which we package the LTO
linker binaries in the release.
Has anybody tried LLD on Windows for D already?
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov
wrote:
But it is always assumed that a value can be moved.
It's not just assumed, it's a key requirement for structs in D,
as the compiler can move stuff automatically this way (making a
bitcopy and then eliding the postblit ctor
Hi,
On Monday, 31 July 2017 at 07:22:06 UTC, Maxim Fomin wrote:
1) Support of linking in win64?
LDC: MSVC targets, both 32 and 64 bits, fully supported since a
year or so. Requires Visual Studio 2015+.
2) What is the support of other platforms? AFAIK there was
progress on Android.
LDC:
On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote:
On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote:
On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote:
Is there a future where we can see WebAssembly as part of D?
Seeing Rusts backbone already producing wasm is impressive.
On Wednesday, 26 July 2017 at 15:55:14 UTC, Wulfklaue wrote:
But how about NOT always adding new feature and actually making
things more easy for new people.
People need to eventually understand that all the energy wasted
for complaining about D/the community/whatever would be so much
more
On Saturday, 1 October 2016 at 19:10:47 UTC, Martin Nowak wrote:
Just tried to fix the float/double initialization w/ signaling
NaNs [¹], but it seems we can't reliably do that for all
backends/architectures. Any additional move of float might
convert SNaNs to QNaNs (quiet NaNs). This has also
On Wednesday, 26 July 2017 at 20:23:25 UTC, Ola Fosheim Grøstad
wrote:
so it doesn't make a whole lot of sense telling people to
"improve" on it if they haven't even adopted it (in production).
My point was improving vs. complaining. Both take some analysis
to figure out an issue, but then
On Wednesday, 5 July 2017 at 20:12:40 UTC, H. S. Teoh wrote:
I vaguely remember there was talk about compressing symbols
when they get too long... is there any hope of seeing this
realized in the near future?
LDC has an experimental feature replacing long names by their
hash; ldc2 -help:
On Friday, 18 August 2017 at 12:09:04 UTC, kinke wrote:
On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote:
For some reason, the LDC default initializes the structure,
even if initialization of all its members is specified as
void. I believe that this is wrong.
Afaik, this has
On Saturday, 19 August 2017 at 06:20:28 UTC, Nicholas Wilson
wrote:
is there a way to not assign to out variables?
I don't think so. Is there a good reason not to return the matrix
directly (taking advantage of in-place construction)?
float[M][M] f()
{
float[M][M] mean = void;
//
On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote:
For some reason, the LDC default initializes the structure,
even if initialization of all its members is specified as void.
I believe that this is wrong.
Afaik, this has been brought up multiple times already and is so
by
On Monday, 15 May 2017 at 10:41:55 UTC, ag0aep6g wrote:
TL;DR: Changing the ABI of delegates so that the context
pointer is passed last would make functions implicitly
convertible to delegates, no?
In the discussion of issue 17156 [1], Eyal asks why functions
(function pointers?) don't
On Thursday, 11 May 2017 at 11:31:58 UTC, Nikolay wrote:
On Thursday, 11 May 2017 at 11:10:50 UTC, Joakim wrote:
Well, if you don't like what's available and NetBSD doesn't
provide them... up to you to decide where that leads.
In any case it was not my decision. LDC does not use x87 for
math
On Monday, 15 May 2017 at 17:03:20 UTC, ag0aep6g wrote:
On 05/15/2017 02:27 PM, kinke wrote:
Some additional context: https://github.com/dlang/dmd/pull/5232
What I take from that is that changing the way arguments are
passed (particularly if they're reversed or not) is going to
break a ton
On Monday, 15 May 2017 at 20:14:49 UTC, ag0aep6g wrote:
Say, the function ABI uses EAX, EBX, and ECX for the first
three arguments (in that order). For a function call `f(1, 2)`
that means:
EAX: 1
EBX: 2
ECX: not used
For a delegate call `dg(1, 2)` I'd also put 1 and 2 into EAX
On Tuesday, 20 June 2017 at 17:52:59 UTC, Dan Walmsley wrote:
How do I link in the run time and gc, etc?
In your case, you firstly need to cross-compile druntime to your
target. This means compiling most files in the src subdirectory
of LDC's druntime [1], excluding obvious ones like
On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:
Congratulations to Iain and the gdc team. :)
+1. Awesome!
On Friday, 8 September 2017 at 08:07:25 UTC, Daniel N wrote:
I was just reading the LLVM release notes.
Looks quite interesting, did anyone try it?
http://ziglang.org/
I noticed it too in the release notes, browsed to the page,
scrolled down to the first code samples and was immediately put
On Tuesday, 29 August 2017 at 05:10:25 UTC, bitwise wrote:
I needed some C# style events, so I rolled my own. Long story
short, the result was unsatisfactory.
[...]
Anyways, I threw together some code while thinking about what
an event may look like in D:
[...]
I like the C# event
Okay so I'm (sadly) used to every ~10th forum.dlang.org web
request to take something like 10-15 seconds to get a response
(while the other ~9 are instantaneous). But the last couple of
days, the Wiki is hardly usable (editing last night took > 1
minute for the page to reload), and Travis CI
On Sunday, 24 September 2017 at 21:01:06 UTC, Johan Engelen wrote:
So... what's correct? :-)
2.075+. ;)
See https://github.com/dlang/dmd/pull/6754.
On Wednesday, 30 August 2017 at 15:35:57 UTC, bitwise wrote:
-What if I want an event to lock a shared mutex of the
enclosing object, without storing a pointer to that mutex
inside the event itself (and every single other event in the
object)?
-What if I want an event to call a method of the
On Wednesday, 1 November 2017 at 15:15:27 UTC, Daniel Fitzpatrick
wrote:
I am following this short tutorial on compiling a shared lib:
https://wiki.dlang.org/Call_D_from_Ruby_using_FFI
Because it's on Windows I am using these compiler options:
-shared -m64 -defaultlib=libphobos2.so i.d
On Saturday, 5 May 2018 at 15:22:04 UTC, Bolpat wrote:
I once proposed that `in` can mean `const scope ref` that also
binds rvalues.
https://github.com/dlang/DIPs/pull/111#issuecomment-381911140
We could make `in` be something similar to `inline`. The
compiler can implement it as stated above
3. When deciding to move a struct instance, the compiler MUST
emit a call to the struct's __move_post_blt after blitting the
instance and before releasing the memory containing the old
instance. __move_post_blt MUST receive references to both the
pre- and post-move instances.
This implies
On Thursday, 17 May 2018 at 12:36:29 UTC, Shachar Shemesh wrote:
Again, as far as I know, structs are not copied when passed as
arguments. They are allocated on the caller's stack and a
reference is passed to the callee. If that's the case, no move
(of any kind) is done.
That's the exception
On Thursday, 17 May 2018 at 15:23:50 UTC, kinke wrote:
See IR for https://run.dlang.io/is/1JIsk7.
I should probably emphasize that the LLVM `byval` attribute is
strange at first sight. Pseudo-IR `void foo(S* byval param); ...
foo(S* byarg arg);` doesn't mean that the IR callee gets the S*
On Thursday, 17 May 2018 at 19:11:27 UTC, Shachar Shemesh wrote:
On 17/05/18 18:47, kinke wrote:
Since clang is able to compile this struct and do everything
with it, and since the existence of the move constructor
requires the precise same type of hooking as is needed in this
case, I tend to
On Tuesday, 26 June 2018 at 17:38:42 UTC, Manu wrote:
I know, but it's still the reference compiler, and it should at
least
to a reasonable job at the kind of D code that it's
*recommended* that
users write.
I get your point, but IMO it's all about efficient allocation of
the manpower we
On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:
On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
I don't know who's the current maintainer of the Arch Linux D
packages. ldc1.7.0 from the Arch repositories doesn't work
with -fsanitize=address right now, it fails to link. I
On Tuesday, 16 January 2018 at 13:09:06 UTC, Daniel Kozak wrote:
On Tue, Jan 16, 2018 at 12:51 PM, Joakim via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
On Monday, 15 January 2018 at 13:25:26 UTC, Daniel Kozak wrote:
So why not to use cross compilation?
As I said before, you
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:
* three compilers
Not sure why that's a bad thing. They all have their ups and
downs:
- dmd SUPER fast compilation
- ldc multiarch + good optimization + cross-compilation
-
On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei
Alexandrescu wrote:
I heard ldc already uses its embedded variant for linking
programs (on Widows? Posix? 32bit? 64bit?).
Currently only for Windows-MSVC targets (both 32 and 64 bits) and
only when specifying the `-link-internally` switch.
Leaking may be an issue. This currently works:
```
static const(int)* global;
auto foo(const int param)
{
return { global = return param + 10; };
}
void main()
{
{
int arg = 42;
auto dg = foo(42);
auto r = dg();
assert(r == 52);
}
assert(*global
On Thursday, 2 August 2018 at 21:28:27 UTC, kinke wrote:
Leaking may be an issue.
Ah, I guess that's why you mentioned the use-as-rvalue
requirement.
On Thursday, 2 August 2018 at 15:12:10 UTC, Steven Schveighoffer
wrote:
On 8/2/18 11:00 AM, Kagamin wrote:
I suppose it's mostly for mutability, so if it's const, it can
be optimized based on type information only:
auto foo(in int x)
{
return { return x + 10; };
}
I'm not sure what you
On Friday, 3 August 2018 at 14:46:59 UTC, Jonathan Marler wrote:
After thinking about it more I suppose it wouldn't be that
complicated to implement. For delegate literals, you already
need to gather a list of all the data you need to put on the
heap, and if it can all fit inside a pointer,
On Friday, 3 August 2018 at 16:46:53 UTC, Jonathan Marler wrote:
Maybe you could provide an example or 2 to demonstrate why
these would be requirements...we may have 2 different ideas on
how this would be implemented.
auto foo(/*mutable*/ int x)
{
return { return ++x; };
}
void main()
{
A slightly more complex example, illustrating that it wouldn't be
enough to check that the delegate body itself doesn't mutate the
captured variable:
```
int delegate() increment;
auto foo(int x)
{
increment = () => ++x;
return () => x;
}
void main()
{
auto dg = foo(42);
auto
On Sunday, 29 July 2018 at 11:03:43 UTC, Jonathan M Davis wrote:
I guess that the argument at that point is that you would have
to put them in separate D modules, just like you would if they
were extern(D) functions.
Yep, that'd sound acceptable to me, implying that
```
extern(C++, cppns) {
On Thursday, 26 July 2018 at 07:38:08 UTC, Shachar Shemesh wrote:
Mecca doesn't call that. Should it? Can that be the problem?
Very likely so. It's (normally) used in core.thread.Thread's
push/popContext() when switching into a fiber.
On Saturday, 4 August 2018 at 13:52:54 UTC, Steven Schveighoffer
wrote:
No, it depends on and is dictated by D's delegate system. The
delegate receives the context pointer by value.
Absolutely right, thx for clarifying.
Argh, should read `*cast(int*) `.
On Saturday, 4 August 2018 at 12:21:18 UTC, Steven Schveighoffer
wrote:
You don't even need to make a copy to show problems, the
context isn't passed by reference:
const r1 = dg();
const r2 = dg();
assert(r1 == 43 && r2 == 44); // would fail with optimization.
-Steve
This depends on the
This limitation really seems to make no sense, especially since
you can split up a C++ namespace across multiple D modules, just
not inside a single module.
On Monday, 20 August 2018 at 22:16:09 UTC, Jacob Carlborg wrote:
At the third line there's a call from
object.TypeInfo_Class.getHash. I looked up to see what the
"getHash" method is doing in druntime [2], the method looks
like this:
override size_t getHash(scope const void* p) @trusted const
On Wednesday, 22 August 2018 at 19:25:40 UTC, Jacob Carlborg
wrote:
This could be solved, I think, with having "TypeInfo.getHash" a
template taking the actual type and not void*. That template
can then inspect if the passed type is a D class or any other
type of class and act accordingly.
It
Thanks a lot, Manu, I'm a huge fan of this.
Wrt. binding rvalues to mutable refs, we could introduce
something like `-transition=rval_to_mutable_ref` to have the
compiler list all matching call sites.
Wrt. `auto ref`, I'd very much like to see its semantics change
to 'pass this argument in
On Tuesday, 17 July 2018 at 18:31:18 UTC, Russel Winder wrote:
This would seem to imply that you can't use Vibe.d 0.8.4 with
DMD 2.081.0.
I think that regression was the main reason for early 2.081.1.
On Tuesday, 17 July 2018 at 19:39:32 UTC, Russel Winder wrote:
It seems that the LDC 1.11 branch in the GitHub repository has
the DMD 2.081.0 problem.
If you're referring to branch merge-2.081, that one doesn't exist
anymore. master/beta2 are based on 2.081.1+ and should thus be
fixed.
On Sunday, 15 July 2018 at 20:29:29 UTC, tcb wrote:
Is it possible to completely remove the C runtime on windows,
and if so how?
This works for me:
extern(C) int mainCRTStartup() { return 0; }
dmd -m32mscoff -betterC -L/subsystem:CONSOLE main.d
=> 1.5 kB .exe.
1 - 100 of 671 matches
Mail list logo
