• Joseph Rushton Wakeling (5/5) Aug 23 2013 I recall from discussion a while back that various custom allocators are...
• deadalnix (3/10) Aug 23 2013 I see Andrei running away !
• Andrej Mitrovic (3/4) Aug 23 2013 I see an upcoming drinking game at the next dconf. A shot of
• Jacob Carlborg (5/7) Aug 23 2013 It would be pretty bad if the allocator problem hasn't been solved a
• Namespace (2/6) Aug 23 2013 Or auto ref. ;)
• Dicebot (3/11) Aug 23 2013 Comparing to allocators, "auto ref" is only worth sip of beer.
• Namespace (2/14) Aug 23 2013 As long as it is german beer... ;)
• Peter Alexander (6/14) Aug 23 2013 Or shared.
• w0rp (1/1) Aug 23 2013 new AllocatorPost;
• Namespace (3/18) Aug 23 2013 Oh, these I've completely forgotten. The most of these are much
• H. S. Teoh (12/33) Aug 23 2013 Yeah this one is pretty high up on my wishlist right now. But it seems
• Peter Alexander (4/9) Aug 23 2013 I'm thinking mainly of const postblit, and the ramifications of
• Jonathan M Davis (4/9) Aug 23 2013 Ooh. I keep forgetting about that. That's a big one and is arguably post...
• Timon Gehr (3/7) Aug 23 2013 What problem does const postblit have that a const constructor does not
• Peter Alexander (25/34) Aug 23 2013 Currently, const postblit completely breaks the type system.
• Andrej Mitrovic (6/9) Aug 23 2013 Apparently, but it's not what happens. The compiler optimizes the call
• Timon Gehr (21/56) Aug 24 2013 I think this line should fail for lack of an appropriately qualified
• Jonathan M Davis (10/19) Aug 23 2013 A copy constructor creates a new object from scratch, so it doesn't modi...
• Jonathan M Davis (16/23) Aug 23 2013 Just the issues with it an Object AFAIK.
• Timon Gehr (2/8) Aug 23 2013 Add compile-time reflection.
• Kapps (4/17) Aug 23 2013 The current compile-time reflection seems to be capable of doing
• H. S. Teoh (6/20) Aug 23 2013 I thought __traits solved that problem? In an ugly way, perhaps, but is
• David Nadlinger (21/30) Aug 23 2013 The problem is that the language does not define how to deal with
• Namespace (3/18) Aug 24 2013 Or:
• David Nadlinger (4/9) Aug 24 2013 That's not a language issue, that's a compiler feature request
• Namespace (4/14) Aug 24 2013 What's about the probable change of virtual by default -> final
• Andrej Mitrovic (4/6) Aug 24 2013 Btw, can someone find the link to the forum thread where the last
• Kapps (5/12) Aug 24 2013 It seemed like eventually Walter supported virtual by default,
• luminousone (4/17) Aug 24 2013 Pretty sure Walter supported final by default, he even laid out a
• Namespace (3/10) Aug 25 2013 http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq@forum.dlang.org?page=...
• Andrej Mitrovic (2/3) Aug 25 2013 Thanks!
• Mr. Anonymous (4/19) Aug 25 2013 How about adding those to the TODO list?
• David Nadlinger (8/10) Aug 25 2013 … starting with the fact that we don't have a well-defined memory
• Dicebot (2/13) Aug 25 2013 It is a wonder it works at all! :D
• Dmitry Olshansky (6/21) Aug 26 2013 Well C++ got away with it for 10+ years not even having a notion of a
• Dicebot (6/10) Aug 26 2013 What I was (half-)joking about here is that D has _lot_ of
• deadalnix (4/17) Aug 26 2013 Well, first it would break a lot of code; And second, we'd
• Maxim Fomin (3/4) Aug 23 2013 So far, this is the best description of current situation
• Joseph Rushton Wakeling (2/3) Aug 23 2013 That was what I feared ... :-)
• Brian Rogoff (14/18) Aug 23 2013 It seems you're far from being the only interested party!
• Dmitry Olshansky (8/23) Aug 23 2013 It works. It has no updates for some time, but there isn't anything
• H. S. Teoh (15/32) Aug 23 2013 lol... seriously though, when *are* we going to get working allocators?

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

I recall from discussion a while back that various custom allocators are in the 
works as alternatives to the GC.

Can anyone advise on their status and give a rough idea of what will be offered?

Perhaps this should have gone in D.learn but as it's about language
development, 
the main forum seems like the best place to open discussion.

"deadalnix" <deadalnix gmail.com> writes:

On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton 
Wakeling wrote:
 I recall from discussion a while back that various custom 
 allocators are in the works as alternatives to the GC.

 Can anyone advise on their status and give a rough idea of what 
 will be offered?

 Perhaps this should have gone in D.learn but as it's about 
 language development, the main forum seems like the best place 
 to open discussion.

I see Andrei running away !

"Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:

On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of 
whiskey anytime anyone mentions allocators. :P

Jacob Carlborg <doob me.com> writes:

On 2013-08-23 13:33, Andrej Mitrovic wrote:

 I see an upcoming drinking game at the next dconf. A shot of whiskey
 anytime anyone mentions allocators. :P

It would be pretty bad if the allocator problem hasn't been solved a 
year from now, assuming the next dconf will be in about a year.

-- 
/Jacob Carlborg

"Namespace" <rswhite4 googlemail.com> writes:

On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

"Dicebot" <public dicebot.lv> writes:

On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

 Or auto ref. ;)

Comparing to allocators, "auto ref" is only worth sip of beer. 
Those are pretty close to "eternal classics" state :)

"Namespace" <rswhite4 googlemail.com> writes:

On Friday, 23 August 2013 at 13:06:22 UTC, Dicebot wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

 Or auto ref. ;)

 Comparing to allocators, "auto ref" is only worth sip of beer. 
 Those are pretty close to "eternal classics" state :)

As long as it is german beer... ;)

"Peter Alexander" <peter.alexander.au gmail.com> writes:

On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

 Or auto ref. ;)

Or shared.

Or const.

Or scope.

Or Object methods.

There's quite a few unresolved issues!

"w0rp" <devw0rp gmail.com> writes:

new AllocatorPost;

"Namespace" <rswhite4 googlemail.com> writes:

On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

 Or auto ref. ;)

 Or shared.

 Or const.

 Or scope.

 Or Object methods.

 There's quite a few unresolved issues!

Oh, these I've completely forgotten. The most of these are much 
older than auto ref. :D

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Aug 23, 2013 at 09:55:05PM +0200, Namespace wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic
wrote:
On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of
whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Or shared.

Or const.


What's the problem with const again?


Or scope.


Yeah this one is pretty high up on my wishlist right now. But it seems
like everybody knows what it should do, but nobody knows how to
implement it.


Or Object methods.


Wasn't the latest consensus to get rid of them all? Though it does put
the implementation at odds with TDPL...


There's quite a few unresolved issues!

 
 Oh, these I've completely forgotten. The most of these are much
 older than auto ref. :D

There's also the new AA implementation, which hasn't progressed in 2
years. :-(


T

-- 
IBM = I'll Buy Microsoft!

"Peter Alexander" <peter.alexander.au gmail.com> writes:

On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of 
solving that.


Or Object methods.


 Wasn't the latest consensus to get rid of them all? Though it 
 does put
 the implementation at odds with TDPL...

Yeah, I think so, but doing so is a really big change!

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, August 23, 2013 22:08:40 Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

 
 I'm thinking mainly of const postblit, and the ramifications of
 solving that.

Ooh. I keep forgetting about that. That's a big one and is arguably postblit's 
biggest flaw.

- Jonathan M Davis

Timon Gehr <timon.gehr gmx.ch> writes:

On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

 I'm thinking mainly of const postblit, and the ramifications of solving
 that.

What problem does const postblit have that a const constructor does not 
have?

"Peter Alexander" <peter.alexander.au gmail.com> writes:

On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:
 On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

 I'm thinking mainly of const postblit, and the ramifications 
 of solving
 that.

 What problem does const postblit have that a const constructor 
 does not have?

Currently, const postblit completely breaks the type system.

struct Foo
{
     this(this) { *p = 2; }
     int* p;
}

void main()
{
     import std.stdio;
     immutable int i = 1;
     const(Foo) a = const(Foo)(&i);
     const(Foo) b = a;
     writeln(a.p, " ", *a.p);
     writeln(b.p, " ", *b.p);
     writeln(&i, " ", i);
}

For me, this gives:

7FFF5257D418 2
7FFF5257D418 2
7FFF5257D418 1

The immutable int is changed, and apparently the same address has 
two different values at the same time!

I'm not aware of any way to do this with constructors, but maybe 
I'm just not aware :-)

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 8/24/13, Peter Alexander <peter.alexander.au gmail.com> wrote:
 The immutable int is changed

Yeah.

 and apparently the same address has
 two different values at the same time!

Apparently, but it's not what happens. The compiler optimizes the call
to writeln by substituting 'i' with its value. This would be a safe
optimization based on immutability rules, were it not for the postblit
bug.

Timon Gehr <timon.gehr gmx.ch> writes:

On 08/24/2013 12:42 AM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:
 On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

 I'm thinking mainly of const postblit, and the ramifications of solving
 that.

 What problem does const postblit have that a const constructor does
 not have?

 Currently, const postblit completely breaks the type system.

 struct Foo
 {
      this(this) { *p = 2; }
      int* p;
 }
 ...

That's a mutable postblit, but I see the point.

 void main()
 {
      import std.stdio;
      immutable int i = 1;
      const(Foo) a = const(Foo)(&i);
      const(Foo) b = a;

I think this line should fail for lack of an appropriately qualified 
postblit.

      writeln(a.p, " ", *a.p);
      writeln(b.p, " ", *b.p);
      writeln(&i, " ", i);
 }

 For me, this gives:

 7FFF5257D418 2
 7FFF5257D418 2
 7FFF5257D418 1

 The immutable int is changed, and apparently the same address has two
 different values at the same time!

 I'm not aware of any way to do this with constructors, but maybe I'm
 just not aware :-)

import std.stdio;

void main(){
     void check(immutable(int)* ptr){
         writeln(ptr," ",*ptr);
     }
     struct S{
         immutable(int) x;
         this(int)const{
             check(&x);
             x=2;
             check(&x);
         }
     }
     auto s = S(0);
}

7FFFAFAA4B80 0
7FFFAFAA4B80 2

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, August 23, 2013 22:20:21 Timon Gehr wrote:
 On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

 
 I'm thinking mainly of const postblit, and the ramifications of solving
 that.

 
 What problem does const postblit have that a const constructor does not
 have?

A copy constructor creates a new object from scratch, so it doesn't modify 
anything, and creating it as const is fine. postblit on the other hand does a 
memcopy of the object first and then modifies select portions of the copy. When 
constructing a const or immutable object, that would mean that you have to 
modify a const or immutable object in order to mutate the portions that the 
postblit is supposed to be mutating. We need a way to construct a copy rather 
than copy and mutate, so AFAIK, we basically need to add copy constructors to 
solve this problem.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, August 23, 2013 13:03:02 H. S. Teoh wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
Or const.


 
 What's the problem with const again?

Just the issues with it an Object AFAIK.
Or Object methods.
 
 Wasn't the latest consensus to get rid of them all? Though it does put
 the implementation at odds with TDPL...

That's what we agreed on. The problem is implementing the changes. I have a 
pull for druntime which starts the process for opEquals, but compiler changes 
are likely to be required to get all of this to work, and we may need the AA 
implementation to be fixed first as well. So, there are some serious
roadblocks. 
The most recent discussion on it was

http://forum.dlang.org/thread/mailman.214.1369617617.13711.digitalmars-d puremagic.com

though it looks like Kenji's reply in that thread was split off:

http://forum.dlang.org/thread/7851915.gvRHKl6iG7 lyonel

An enterprising compiler dev could probably get us most of the way there 
pretty quickly though based on some of the ideas in that discussion. I don't 
know if we can avoid needing to fix the AAs first or not though, and you know 
better than most of us how much of a mess that is.

- Jonathan M Davis

Timon Gehr <timon.gehr gmx.ch> writes:

On 08/23/2013 07:27 PM, Peter Alexander wrote:

 Or shared.

 Or const.

 Or scope.

 Or Object methods.

 There's quite a few unresolved issues!

Add compile-time reflection.

"Kapps" <opantm2+spam gmail.com> writes:

On Friday, 23 August 2013 at 20:18:53 UTC, Timon Gehr wrote:
 On 08/23/2013 07:27 PM, Peter Alexander wrote:

 Or shared.

 Or const.

 Or scope.

 Or Object methods.

 There's quite a few unresolved issues!

 Add compile-time reflection.

The current compile-time reflection seems to be capable of doing 
most things to at least generate runtime reflection. What do you 
find missing with it? Or is it just the way it's presented?

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
 On 08/23/2013 07:27 PM, Peter Alexander wrote:

Or shared.

Or const.

Or scope.

Or Object methods.

There's quite a few unresolved issues!

 
 Add compile-time reflection.

I thought __traits solved that problem? In an ugly way, perhaps, but is
there something that can't be solved with __traits?


T

-- 
Two wrongs don't make a right; but three rights do make a left...

"David Nadlinger" <code klickverbot.at> writes:

On Friday, 23 August 2013 at 20:42:20 UTC, H. S. Teoh wrote:
 On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
 On 08/23/2013 07:27 PM, Peter Alexander wrote:
 […]
There's quite a few unresolved issues!

 
 Add compile-time reflection.

 I thought __traits solved that problem? In an ugly way, 
 perhaps, but is
 there something that can't be solved with __traits?

The problem is that the language does not define how to deal with 
"forward references". At all.

There are lots of cases where this matters in practice, for 
example when using the information obtained by 
__traits(allMembers, T) to add a new member to T (e.g. in a 
serialization library). But the canonical example probably is 
simply:
–––
static if (!is(typeof(b))) enum a = 0;
static if (!is(typeof(a))) enum b = 0;
// What is defined? a? b? both? Or is this illegal code?
–––

Right now, DMD is rather liberal in what it accepts, but what 
exactly is legal is not clear, and evaluation order is completely 
unspecified. This is a huge problem, as you end up writing a 
piece of code and seeing that it compiles fine and behaves as you 
would intuitively expect, assume that it is legal, only to have 
the compiler choke on it or behave differently when the next 
release comes out.

David

"Namespace" <rswhite4 googlemail.com> writes:

On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

 Or auto ref. ;)

 Or shared.

 Or const.

 Or scope.

 Or Object methods.

 There's quite a few unresolved issues!

Or: 
http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

"David Nadlinger" <code klickverbot.at> writes:

On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
 wrote:
 There's quite a few unresolved issues!

 Or: 
 http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

That's not a language issue, that's a compiler feature request 
that does not affect the language semantics at all.

David

"Namespace" <rswhite4 googlemail.com> writes:

On Saturday, 24 August 2013 at 20:56:09 UTC, David Nadlinger 
wrote:
 On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
 wrote:
 There's quite a few unresolved issues!

 Or: 
 http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

 That's not a language issue, that's a compiler feature request 
 that does not affect the language semantics at all.

 David

What's about the probable change of virtual by default -> final 
by default?

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

Btw, can someone find the link to the forum thread where the last
discussion of this took place? I remember Walter agreeing to
something, but can't recall anymore.

"Kapps" <opantm2+spam gmail.com> writes:

On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:
 On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

 Btw, can someone find the link to the forum thread where the 
 last
 discussion of this took place? I remember Walter agreeing to
 something, but can't recall anymore.

It seemed like eventually Walter supported virtual by default, 
but nothing came of it. For some reason I can't find the thread 
anymore with Google.

"luminousone" <rd.hunt gmail.com> writes:

On Saturday, 24 August 2013 at 22:41:54 UTC, Kapps wrote:
 On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
 wrote:
 On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

 Btw, can someone find the link to the forum thread where the 
 last
 discussion of this took place? I remember Walter agreeing to
 something, but can't recall anymore.

 It seemed like eventually Walter supported virtual by default, 
 but nothing came of it. For some reason I can't find the thread 
 anymore with Google.

Pretty sure Walter supported final by default, he even laid out a 
transition plan as I recall. Seems like Manu was involved, so 
asking him might bear fruit on that question.

"Namespace" <rswhite4 googlemail.com> writes:

On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:
 On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

 Btw, can someone find the link to the forum thread where the 
 last
 discussion of this took place? I remember Walter agreeing to
 something, but can't recall anymore.

http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq forum.dlang.org?page=28#post-koqkhc:244nn:241:40digitalmars.com

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 8/25/13, Namespace <rswhite4 googlemail.com> wrote:
 http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq forum.dlang.org?page=28#post-koqkhc:244nn:241:40digitalmars.com

Thanks!

"Mr. Anonymous" <mailnew4ster gmail.com> writes:

On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

 I see an upcoming drinking game at the next dconf. A shot of 
 whiskey anytime anyone mentions allocators. :P

 Or auto ref. ;)

 Or shared.

 Or const.

 Or scope.

 Or Object methods.

 There's quite a few unresolved issues!

How about adding those to the TODO list?
e.g. http://dlang.org/todo.html
Or make a wiki page?

"David Nadlinger" <code klickverbot.at> writes:

On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 Or shared

… starting with the fact that we don't have a well-defined memory 
model at all – on a fundamental level, multithreaded programming 
in D is guesswork (resp. looking at the compiler implementation) 
right now!

 […] There's quite a few unresolved issues!

Also add aliasing semantics to the list: 
http://d.puremagic.com/issues/show_bug.cgi?id=10750

David

"Dicebot" <public dicebot.lv> writes:

On Sunday, 25 August 2013 at 22:46:16 UTC, David Nadlinger wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
 wrote:
 Or shared

 … starting with the fact that we don't have a well-defined 
 memory model at all – on a fundamental level, multithreaded 
 programming in D is guesswork (resp. looking at the compiler 
 implementation) right now!

 […] There's quite a few unresolved issues!

 Also add aliasing semantics to the list: 
 http://d.puremagic.com/issues/show_bug.cgi?id=10750

 David

It is a wonder it works at all! :D

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

26-Aug-2013 03:03, Dicebot пишет:
 On Sunday, 25 August 2013 at 22:46:16 UTC, David Nadlinger wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 Or shared

 … starting with the fact that we don't have a well-defined memory
 model at all – on a fundamental level, multithreaded programming in D
 is guesswork (resp. looking at the compiler implementation) right now!

 […] There's quite a few unresolved issues!

 Also add aliasing semantics to the list:
 http://d.puremagic.com/issues/show_bug.cgi?id=10750

 David

 It is a wonder it works at all! :D

Well C++ got away with it for 10+ years not even having a notion of a 
thread. And since globals are defined as thread-local, there is some 
notion of memory model isn't it? ;)

-- 
Dmitry Olshansky

"Dicebot" <public dicebot.lv> writes:

On Monday, 26 August 2013 at 07:55:56 UTC, Dmitry Olshansky wrote:
 It is a wonder it works at all! :D

 Well C++ got away with it for 10+ years not even having a 
 notion of a thread. And since globals are defined as 
 thread-local, there is some notion of memory model isn't it? ;)

What I was (half-)joking about here is that D has _lot_ of 
crucial design problems, listing them all at once can inspire 
truly apocalyptic feelings. And still in practice it works and 
works pretty damn good. Can a mortal mind even imagine how 
awesome can it be if all those issues are addressed and fixed? :)

"deadalnix" <deadalnix gmail.com> writes:

On Monday, 26 August 2013 at 14:06:42 UTC, Dicebot wrote:
 On Monday, 26 August 2013 at 07:55:56 UTC, Dmitry Olshansky 
 wrote:
 It is a wonder it works at all! :D

 Well C++ got away with it for 10+ years not even having a 
 notion of a thread. And since globals are defined as 
 thread-local, there is some notion of memory model isn't it? ;)

 What I was (half-)joking about here is that D has _lot_ of 
 crucial design problems, listing them all at once can inspire 
 truly apocalyptic feelings. And still in practice it works and 
 works pretty damn good. Can a mortal mind even imagine how 
 awesome can it be if all those issues are addressed and fixed? 
 :)

Well, first it would break a lot of code; And second, we'd 
probably discover a whole new class of problem. But yeah, that'd 
be great :P

"Maxim Fomin" <maxim maxim-fomin.ru> writes:

On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

So far, this is the best description of current situation 
regarding allocators.

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

On 23/08/13 13:29, deadalnix wrote:
 I see Andrei running away !

That was what I feared ... :-)

"Brian Rogoff" <brogoff gmail.com> writes:

On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton 
Wakeling wrote:
 I recall from discussion a while back that various custom 
 allocators are in the works as alternatives to the GC.

 Can anyone advise on their status and give a rough idea of what 
 will be offered?

It seems you're far from being the only interested party!

Has anyone tried porting an existing allocator library from C++? 
Looking over the dconf proceedings, HeapLayers was mentioned as 
an inspiration for a future D allocators library; would a port 
make sense?

I remember seeing a D2 region allocator, but it appeared to be 
abandonware.

Assuming you have a really great allocator library, how would 
that work with the existing GC requiring features of D? For 
example, could you have all of your slicing, classes, exceptions, 
etc. handled by a region allocator?

-- Brian

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

23-Aug-2013 18:31, Brian Rogoff пишет:
 On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton Wakeling wrote:
 I recall from discussion a while back that various custom allocators
 are in the works as alternatives to the GC.

 Can anyone advise on their status and give a rough idea of what will
 be offered?

 It seems you're far from being the only interested party!

 Has anyone tried porting an existing allocator library from C++? Looking
 over the dconf proceedings, HeapLayers was mentioned as an inspiration
 for a future D allocators library; would a port make sense?

 I remember seeing a D2 region allocator, but it appeared to be abandonware.

It works. It has no updates for some time, but there isn't anything 
wrong with it. It just failed to establish the new allocator scheme so 
it's just a nice piece of 3rd party library.


 Assuming you have a really great allocator library, how would that work
 with the existing GC requiring features of D? For example, could you
 have all of your slicing, classes, exceptions, etc. handled by a region
 allocator?

Hardly (if we are not to forget about  safe), but I assume a 
thread-local GC would solve a lot of problems.


-- 
Dmitry Olshansky

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Aug 23, 2013 at 03:48:59PM +0200, Maxim Fomin wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
I see Andrei running away !

 
 So far, this is the best description of current situation regarding
 allocators.

lol... seriously though, when *are* we going to get working allocators?
I mean, right now we don't even have a concrete proposal that we can
destroy. And we've been talking about allocators for how many years now?


On Fri, Aug 23, 2013 at 04:31:54PM +0200, Brian Rogoff wrote:
[...]
 Has anyone tried porting an existing allocator library from C++?
 Looking over the dconf proceedings, HeapLayers was mentioned as an
 inspiration for a future D allocators library; would a port make
 sense?

IIRC, we didn't want to follow C++'s implementation, which in practice
is troublesome to use and usually avoided. But what should replace it,
isn't all that clear.


 I remember seeing a D2 region allocator, but it appeared to be
 abandonware.
 
 Assuming you have a really great allocator library, how would that
 work with the existing GC requiring features of D? For example,
 could you have all of your slicing, classes, exceptions, etc.
 handled by a region allocator?

[...]

I suspect the elusive answers to these questions are what's keeping
Andrei on the run. ;-)


T

-- 
Frank disagreement binds closer than feigned agreement.