On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
Hello everyone, I recently started learning D (I come from a
Modern C++ background) and I was curious about closures that
require GC allocation. I wrote this simple example:
[...]
I started to do some changes to the compiler.
htt
On Tuesday, 30 May 2017 at 19:29:38 UTC, deadalnix wrote:
What are your thoughts? Has something similar been proposed
before?
https://wiki.dlang.org/DIP30
Also, while no syntax is provided, this is how SDC works
internally and this is how it can handle multiple context
pointers.
FWIW, I th
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
Hello everyone, I recently started learning D (I come from a
Modern C++ background) and I was curious about closures that
require GC allocation. I wrote this simple example:
auto bar(T)(T x) @nogc
{
return x(10);
On Monday, 29 May 2017 at 21:26:11 UTC, MakersF wrote:
1) Capture by value. This is the ability to have a lambda which
behaves as expected in the example Vittorio showed
That's a known bug in the implementation; it is supposed to work
that way now.
(Though the bug has been open for so long I
On Thursday, 25 May 2017 at 03:10:04 UTC, Adam D. Ruppe wrote:
Snip
I think the discussion is going in two orthogonal directions,
which are:
1) Capture by value. This is the ability to have a lambda which
behaves as expected in the example Vittorio showed
void delegate()[] arr;
for
On Thursday, 25 May 2017 at 05:03:15 UTC, Stanislav Blinov wrote:
Sigh... You're right. We should've renamed the file at the same
time as removing the number from the contents, because
"internets". And I shouldn't have snapped like that. I
apologize.
It's all good :-)
On Thursday, 25 May 2017 at 04:53:14 UTC, Mike Parker wrote:
On Thursday, 25 May 2017 at 03:14:14 UTC, Stanislav Blinov
wrote:
Mike, I've read that README several times over. Yes, a mistake
was made, a number self-assigned. Yes, that is not how it's
done. Yes, we know. Yes. Thanks for the r
On Thursday, 25 May 2017 at 03:14:14 UTC, Stanislav Blinov wrote:
Mike, I've read that README several times over. Yes, a mistake
was made, a number self-assigned. Yes, that is not how it's
done. Yes, we know. Yes. Thanks for the reminder. All is fixed.
Thanks. I wasn't criticizing. It wasn'
On Thursday, 25 May 2017 at 03:42:11 UTC, Adam D. Ruppe wrote:
On Thursday, 25 May 2017 at 03:30:38 UTC, Stanislav Blinov
wrote:
Captures, if any, should be explicit. That is all :)
The current behavior is fine in most cases. The explicit
by-value capture handles the remaining cases.
In my
On Thursday, 25 May 2017 at 03:30:38 UTC, Stanislav Blinov wrote:
Captures, if any, should be explicit. That is all :)
The current behavior is fine in most cases. The explicit by-value
capture handles the remaining cases.
By inference, adding capture syntax at all will also complicate
the w
On Thursday, 25 May 2017 at 03:10:04 UTC, Adam D. Ruppe wrote:
"Currently FunctionLiterals that capture their outer context
(i.e. closures/delegates) require an allocation and the garbage
collector. "
Not necessarily true, make sure you actually mention `scope
delegate` and `alias` params
On Thursday, 25 May 2017 at 01:18:22 UTC, Mike Parker wrote:
label:
if (self.bored) goto disclaimer;
We're well aware. The file name is not indicative of anything.
The README outlines the procedure for DIP submission, including
the format of the filename. The concern is that if you include
On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
If you're interested in contributing, please let me know and
I'll add you as a collaborator.
can i just edit it on the site?
but a few comments:
"Currently FunctionLiterals that capture their outer context
(i.e. closures/delega
On Thursday, 25 May 2017 at 01:13:08 UTC, Stanislav Blinov wrote:
On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:
As a matter of procedure, you don't want to assign a DIP
number to it yourself. I'm pretty sure that is for the DIP
manager.
We're well aware. The file name is not i
On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:
I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
If you're interested in contributing, please let me know and
I'll add you as a collaborator.
As a matter of procedure, you don't want
On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:
On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally pro
On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
If you're interested in contributing, please let me know and
I'll add you as a collaborator.
Yep, I've made a small PR to make m
On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:
On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally propose the C++
syntax, our library solutions are all fat.
Are you
On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally propose the C++
syntax, our library solutions are all fat.
Are you going to create a DIP for this? I would be happy to
contribute,
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally propose the C++ syntax,
our library solutions are all fat.
Are you going to create a DIP for this? I would be happy to
contribute, but I don't feel confident enough to create a DIP on
my own (
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally propose the C++ syntax,
our library solutions are all fat.
:)
On Sunday, 21 May 2017 at 20:09:14 UTC, Stanislav Blinov wrote:
is a function that is generated by the template. It accesses
the frame of create(). Am I missing something?
It does access the frame, but only long enough to copy the values
into the struct there's no reason for that to alloca
On Sunday, 21 May 2017 at 19:43:32 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote:
Looks cool, but it'd still want a GC closure, won't it?
No, it just generates the same struct you'd write manually.
That should work fine with @nogc now.
auto create(
On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote:
Looks cool, but it'd still want a GC closure, won't it?
No, it just generates the same struct you'd write manually. That
should work fine with @nogc now.
On Sunday, 21 May 2017 at 18:17:57 UTC, Adam D. Ruppe wrote:
But, using the struct stuff, we can add some artificial
sweetener now:
return bar(lambda!(x, q{ (int y) => x + y }));
You pass the captures first, then a q{} string literal of the
lambda. Here's the implementation of that lambda te
On Sunday, 21 May 2017 at 04:08:04 UTC, Vittorio Romeo wrote:
This exact statement applied to C++ before C++11, but the
introduction of lambda expression significantly changed the way
people write and think about C++. Sometimes syntactic sugar can
have huge impact on a language.
Oh absolutely
Hi Vittorio, wonderful to see you here after C++Now! :)
On 05/20/2017 09:08 PM, Vittorio Romeo wrote:
>consider this code:
>
> void delegate()[] arr;
>
> foreach(i; 0..5)
> {
> arr ~= () => writeln(i);
> }
>
> foreach(f; arr)
> {
> f();
> }
>
> This is
Thanks for the suggestions regarding the `scope` parameter
attribute. I'll look into it!
On Sunday, 21 May 2017 at 01:30:51 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 00:49:23 UTC, Stanislav Blinov wrote:
[...] you *can* write out the struct now, it just has more
tedious syntax.
Thi
On Sunday, 21 May 2017 at 00:49:23 UTC, Stanislav Blinov wrote:
And it would be nice to be able to store the delegate longer
than current scope...
Important to note that this thing won't be a delegate, since
delegates don't have room to store by-value captures. It can
still be passed to isCal
On Sunday, 21 May 2017 at 00:43:58 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
just manually writing out the struct functor being another
viable one. The c++ syntax sugar is nice, but I can live
without it.
Assembler is viable as well, but it's not
On Sunday, 21 May 2017 at 00:43:58 UTC, Adam D. Ruppe wrote:
What are your thoughts? Has something similar been proposed
before?
It has, and I actually don't hate it, but I also don't think it
is necessary because of the `scope` storage class being one
option and just manually writing out th
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
auto bar(T)(T x) @nogc
Make that `scope T x` and it will compile, using stack
allocation. Only worry is that you must not escape a reference to
the delegate; you are only allowed to use it in that function's
scope.
What are
Hello everyone, I recently started learning D (I come from a
Modern C++ background) and I was curious about closures that
require GC allocation. I wrote this simple example:
auto bar(T)(T x) @nogc
{
return x(10);
}
auto foo(int x) @nogc
{
return bar((int y)
33 matches
Mail list logo
