www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - If you had money to place for a bounty, what would you choose?

reply "Fra" <Fra b.it> writes:
Personally I would love to see this old issue finally 
implemented/fixed:
There can be only one alias this.
https://d.puremagic.com/issues/show_bug.cgi?id=6083

What would your choice be?
Nov 28 2013
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

http://d.puremagic.com/issues/show_bug.cgi?id=11365
Nov 28 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

http://d.puremagic.com/issues/show_bug.cgi?id=9238
Nov 28 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
If I had the money, I'd not just place a bounty, I'd hire a team of
dedicated programmers to work full-time to fix the current AA
implementation, once and for all.  There are at least 76 AA-related
issues[1] on my list, many of which are not just trifling bugs but
fundamental design issues.

I know of at least one person who got turned off D due to an AA bug
(fortunately I rescued the situation by fixing said bug). I'd like for
that not to happen again.

[1] https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=aa%20associative%20hash&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=anywordssubstr&version=D1%20%26%20D2&version=D2&known_name=aa&query_based_on=aa


T

-- 
Кто везде - тот нигде.
Nov 28 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.152.1385681675.3242.digitalmars-d puremagic.com...
 One of the most problematic things is that its implementation is
 sprinkled throughout DMD (each bit interacting in intricate ways with
 its surroundings), object_.d (a sort of hybrid half-user, half-built-in
 struct AssociativeArray), and aaA.d (the core runtime implementation).
 Each of these pieces interact in complex ways with each other, and don't
 always share the same information together.

We can at least fix the hybrid situation: https://github.com/D-Programming-Language/dmd/pull/2856
Nov 28 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.165.1385740581.3242.digitalmars-d puremagic.com...
 On Fri, Nov 29, 2013 at 01:52:19PM +1100, Daniel Murphy wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.152.1385681675.3242.digitalmars-d puremagic.com...
 One of the most problematic things is that its implementation is
 sprinkled throughout DMD (each bit interacting in intricate ways
 with its surroundings), object_.d (a sort of hybrid half-user,
 half-built-in struct AssociativeArray), and aaA.d (the core runtime
 implementation).  Each of these pieces interact in complex ways with
 each other, and don't always share the same information together.

We can at least fix the hybrid situation: https://github.com/D-Programming-Language/dmd/pull/2856

Excellent!! This will cut my budget in half! ;-) What about the AA value type issue?

I don't think we do anything. Let the builtin AA type be simple, slow, and reliable. When performance matters, use a library type you can customize.
Nov 29 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.184.1385824673.3242.digitalmars-d puremagic.com...
 On Sat, Nov 30, 2013 at 05:47:37PM +1100, Daniel Murphy wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.165.1385740581.3242.digitalmars-d puremagic.com...

 What about the AA value type issue?

I don't think we do anything. Let the builtin AA type be simple, slow, and reliable. When performance matters, use a library type you can customize.

Sorry, I meant, what to do about aaA.d not being passed the TypeInfo of AA values. This causes things like aa[key]++ to produce wrong results when the value's .init isn't binary zero.

Oh ok. I guess we fix it.
Nov 30 2013
prev sibling next sibling parent "Fra" <Fra b.it> writes:
On Thursday, 28 November 2013 at 21:38:12 UTC, H. S. Teoh wrote:
 If I had the money, I'd not just place a bounty, I'd hire a 
 team of
 dedicated programmers to work full-time to fix the current AA
 implementation, once and for all.  There are at least 76 
 AA-related
 issues[1] on my list, many of which are not just trifling bugs 
 but
 fundamental design issues.

man-work, maybe even a year?
Nov 28 2013
prev sibling next sibling parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 28.11.2013 22:01, Fra wrote:
 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

https://d.puremagic.com/issues/show_bug.cgi?id=8570 https://d.puremagic.com/issues/show_bug.cgi?id=11616 Actually, 8570 should be closed, and a DIP be written about implicit conversions. -- Simen
Nov 28 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 28, 2013 at 11:06:41PM +0100, Fra wrote:
 On Thursday, 28 November 2013 at 21:38:12 UTC, H. S. Teoh wrote:
If I had the money, I'd not just place a bounty, I'd hire a team of
dedicated programmers to work full-time to fix the current AA
implementation, once and for all.  There are at least 76 AA-related
issues[1] on my list, many of which are not just trifling bugs but
fundamental design issues.

How much would it take? Really, it looks like a few monts of man-work, maybe even a year?

The thing is, it *looks* relatively manageable on the surface, but the more you get into it, the more you realize how fundamentally and irreparably broken it really is. One of the most problematic things is that its implementation is sprinkled throughout DMD (each bit interacting in intricate ways with its surroundings), object_.d (a sort of hybrid half-user, half-built-in struct AssociativeArray), and aaA.d (the core runtime implementation). Each of these pieces interact in complex ways with each other, and don't always share the same information together. My favorite gripe is how struct AssociativeArray knows about the compile-time types of keys and values, but aaA.d has no direct access to that information except via the TypeInfo of the key, passed in at runtime... but it *doesn't* know anything about the *value* type except as an opaque block of bytes, so for example storing value types with non-default .init values does not initialize it correctly -- but most of the time the problem doesn't show up because when you write aa[x]=y, the wrong default initial value gets overwritten by y, which presumably is initialized correctly. But should you write aa[x]++ instead, then the problem suddenly pops up its head. Not to mention, anything involving type qualifiers like const or immutable are horribly broken except for the simplest cases, and are so fundamentally broken it would take a complete rewrite to get it right. To even begin to do anything about this mess, the team has to thoroughly understand dmd internals, aaA.d, and struct AssociativeArray. Then they have to figure out how to extricate the AA-dependent parts of dmd out of all the places they're sprinkled in, *without* breaking the rest of the language, so that a proper library replacement can be put in its place. (Not to mention that said replacement must be 100% compatible with existing D code, lest hordes of angry users knock down your door -- not a trivial task given the current quirks of AA.) And all the while dmd receives a continuous stream of pull requests every day, so when it's all finally said and done, you'll have a veritable nightmare resolving the conflicts when you merge all the inevitable large-scale changes back to git HEAD. It's not an insurmountable task, of course. But it's not gonna get done with a few scattered volunteer hours here, a few minutes of spare time there. You need a dedicated team of coders actively working on it continuously to get through it all. T -- This is not a sentence.
Nov 28 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 Then they
 have to figure out how to extricate the AA-dependent parts of 
 dmd out of
 all the places they're sprinkled in, *without* breaking the 
 rest of the
 language, so that a proper library replacement can be put in 
 its place.
 (Not to mention that said replacement must be 100% compatible 
 with
 existing D code, lest hordes of angry users knock down your 
 door -- not
 a trivial task given the current quirks of AA.)

The new AAs should be allowed to drop some of the precedent quirks and to introduce several new fresh quicks. Bye, bearophile
Nov 28 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
Nice game "guess linked bug by poster nickname" :)
Nov 28 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-28 22:01, Fra wrote:
 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

Binary compatibility with Objective-C: http://michelf.ca/projects/d-objc/ Or dynamic libraries for Mac OS X. -- /Jacob Carlborg
Nov 29 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 15:08, Manu wrote:

 I've been very excited about this for a long time... why is it sitting
 in limbo?

I don't know. It seems Walter don't want us to be worse than Objective-C, meaning he want ARC. But as far as I understand it, we couldn't come to an agreement on how to implement ARC. But to be able to be compatible with ARC in Objective-C we would need to follow that very
 How is the implementation?

Unfortunately only for 32bit and the legacy runtime. iOS uses the modern runtime. It's also missing some features like blocks and categories.
 Is there a reason nobody seems to be actually considering it for inclusion?
 OSX/iOS are 2 very important platforms, and I too would really love to
 see movement on this work.

I could try and get it up to date again, just do a pull and see what happens. -- /Jacob Carlborg
Nov 29 2013
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-29 15:10:27 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-29 15:08, Manu wrote:
 
 I've been very excited about this for a long time... why is it sitting
 in limbo?

I don't know. It seems Walter don't want us to be worse than Objective-C, meaning he want ARC. But as far as I understand it, we couldn't come to an agreement on how to implement ARC. But to be able to be compatible with ARC in Objective-C we would need to follow that very

Actually, if you want ARC to be compatible with Objective-C, someone familiar with Objective-C memory management has to design and implement the thing. Anything designed to work for Objective-C can easily be retrofitted to work with other D types, but the reverse is not true. So I'd tend to say it'd be better to implement ARC as part of the D/Objective-C project first, otherwise you're trying to solve too many problems at the same time and it becomes a mess. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 29 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-29 14:08:25 +0000, Manu <turkeyman gmail.com> said:

 On 29 November 2013 23:27, Jacob Carlborg <doob me.com> wrote:
 
 Binary compatibility with Objective-C:
 
 http://michelf.ca/projects/d-objc/

I've been very excited about this for a long time... why is it sitting in limbo? How is the implementation? Is there a reason nobody seems to be actually considering it for inclusion? OSX/iOS are 2 very important platforms, and I too would really love to see movement on this work.

If I were Walter, I wouldn't accept it in the state it is currently in. The missing support for the modern runtime makes it look like a gimmick, as the legacy runtime is dead end (Apple is already dropping 32-bit support with new OS X frameworks). And no ARC makes it look bad compared to regular Objective-C. Lacking support for Objective-C categories and for blocks is also problematic. I'm no longer working on D/Objective-C. And while Jacob has updated it to a more modern incarnation of DMD, it's just the minimum to keep it afloat. What this project need is sustained development for I don't know how many months. The implementation is quite good, in my opinion. But then I'm the one who wrote it. ;-) The important thing to keep in mind is that this is a huge and far reaching changeset. It adds things in the parser, in the semantic phase, in code generation, in the back end, and in the runtime. It's full of internal design decisions which I didn't really discuss much with anyone, in most part because most people here are not familiar enough with Objective-C (be it the language, its runtime or its compiled representation) to know what to do. There's also some reverse engineering work to figure out the correct output for compiled code, as this is not much documented. Honestly, this thing is not mere bounty material, it'd be worthy to be a Kickstarter project for about a full year of development time. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 20:33, Michel Fortin wrote:

 If I were Walter, I wouldn't accept it in the state it is currently in.
 The missing support for the modern runtime makes it look like a gimmick,
 as the legacy runtime is dead end (Apple is already dropping 32-bit
 support with new OS X frameworks). And no ARC makes it look bad compared
 to regular Objective-C. Lacking support for Objective-C categories and
 for blocks is also problematic.

The advantage of having it merged would be to avoid keeping the fork up to date. Although this might risk breaking it, don't know how complete the test suite is.
 I'm no longer working on D/Objective-C. And while Jacob has updated it
 to a more modern incarnation of DMD, it's just the minimum to keep it
 afloat. What this project need is sustained development for I don't know
 how many months.

 The implementation is quite good, in my opinion. But then I'm the one
 who wrote it. ;-) The important thing to keep in mind is that this is a
 huge and far reaching changeset. It adds things in the parser, in the
 semantic phase, in code generation, in the back end, and in the runtime.
 It's full of internal design decisions which I didn't really discuss
 much with anyone, in most part because most people here are not familiar
 enough with Objective-C (be it the language, its runtime or its compiled
 representation) to know what to do. There's also some reverse
 engineering work to figure out the correct output for compiled code, as
 this is not much documented.

 Honestly, this thing is not mere bounty material, it'd be worthy to be a
 Kickstarter project for about a full year of development time.

This is most likely correct. -- /Jacob Carlborg
Dec 01 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-02 07:54:11 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-29 20:33, Michel Fortin wrote:
 
 If I were Walter, I wouldn't accept it in the state it is currently in.
 The missing support for the modern runtime makes it look like a gimmick,
 as the legacy runtime is dead end (Apple is already dropping 32-bit
 support with new OS X frameworks). And no ARC makes it look bad compared
 to regular Objective-C. Lacking support for Objective-C categories and
 for blocks is also problematic.

The advantage of having it merged would be to avoid keeping the fork up to date. Although this might risk breaking it, don't know how complete the test suite is.

I think the test suite is solid enough to catch most regression for the current features. But someone familiar with the matter needs to be there and have the time to put some understanding in how fix things when they break. More importantly, someone needs to regularly compile on OS X and run the Objective-C tests. That last part should be done by the auto-tester of course, but since for many contributors it'll be inconvenient to test locally those OS-X-only features I predict it'd slow things down a little. Also, there's some parts of the syntax I'd likely want to revise given that D has UDAs now. Would it make sense to merge changes to the parser just to roll them back later? (I also had an idea of something better for class extensions (categories), but those aren't implemented yet so it does not really matter.) I'm usually quite adverse about releasing unfinished features or products, which probably explains why *I* wouldn't merge. Although I obviously won't oppose it being merged if someone wants to. I'm just not sure it is worth the trouble for the core team right now given the lack of some key features. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Dec 02 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-02 14:27, Michel Fortin wrote:

 Also, there's some parts of the syntax I'd likely want to revise given
 that D has UDAs now. Would it make sense to merge changes to the parser
 just to roll them back later?

That's true, and no, we don't want to roll them back later.
 I'm usually quite adverse about releasing unfinished features or
 products, which probably explains why *I* wouldn't merge. Although I
 obviously won't oppose it being merged if someone wants to. I'm just not
 sure it is worth the trouble for the core team right now given the lack
 of some key features.

I understand that. Although I think it's still usable as it is. It's so cumbersome and verbose to use Objective-C libraries from D that I think it's worth adding these features, even they're not complete. -- /Jacob Carlborg
Dec 02 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-03 16:55:28 +0000, Manu <turkeyman gmail.com> said:

 C++ support in D is 'not complete', but what's there now is still very
 important and not considered a bad partial feature to have.
 I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
 maybe it's worth it in the same sense?
 OSX and iOS are 2 of the most popular platforms on earth. The mobile space
 is probably the most important prospective target for D.
 I can't comment on the state it's in. But if what's there is solid and
 useful like the current C++ support, then it's an important start...?

Here are some issues to consider if you ship it right now: - transitioning to ARC when that is implemented (do we require a compiler flag to enable ARC because it was off by default before and turning it on changes the semantics?) - it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a different runtime which requires different codegen, and Apple has been phasing out 32-bit for some time already - missing categories will force bindings to be somewhat contorted - missing blocks will make some of the newer Objective-C APIs inaccessible. It might have been fine to release that thing 3 years ago with a promise that it'll improve. But today it's plain outdated on all fronts, and if it doesn't come with a believable roadmap about filling the gaps it's going to be seen as a clever gimmick that is not particularly useful. That's not unlike a 16-bit pre-C++98 compiler is not terribly useful today. We're at a transition, and currently on the wrong side of it. The only way to bring it up-to-date is for someone to redo the codegen and to design and implement the missing language features. If merging it will accomplish that, then by all means go ahead. But I somewhat doubt that magically people will start to work a lot more on Objective-C support because it has been merged in. I might be wrong though. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Dec 03 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 04:47, Michel Fortin wrote:

 - it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a
 different runtime which requires different codegen, and Apple has been
 phasing out 32-bit for some time already

BTW, is there much difference between the modern runtime for 32bit and 64bit? I'm thinking, is things like the optimization of using the pointer for storing the data for types like NSNumber used on 32bit with the modern runtime? -- /Jacob Carlborg
Dec 04 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-04 08:32:15 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-12-04 04:47, Michel Fortin wrote:
 
 - it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a
 different runtime which requires different codegen, and Apple has been
 phasing out 32-bit for some time already

BTW, is there much difference between the modern runtime for 32bit and 64bit? I'm thinking, is things like the optimization of using the pointer for storing the data for types like NSNumber used on 32bit with the modern runtime?

The pointer magic for NSNumber is pretty much inconsequential: it just means you need to use the runtime functions everywhere, such as objc_getClass to get a pointer to the class object instead of dereferencing the object yourself. But it's a detail to keep in mind. A big change in the modern runtime is that classes are completely non-fragile, in that you can add a member in a superclass without breaking binary compatibility with derived classes. Which means that instance variables are accessed differently, by checking a global constant to find the right offset (initialized when first loading the class). I think the compiler also has to emit that constant that the runtime will initialize. Another big change is exception handling which now piggyback on the C++ exception mechanism instead of using the inefficient longjump implementation of the previous runtime. There's an optimized path for calling certain methods using a virtual table, but we can skip that in a first release as it's an optimisation (objc_msgSend still work fine in every case). Beside that, they changed all the section names for the binary output, and probably did a some alterations to the binary structure I'm forgetting right now. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Dec 04 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 12:43, Michel Fortin wrote:

 The pointer magic for NSNumber is pretty much inconsequential: it just
 means you need to use the runtime functions everywhere, such as
 objc_getClass to get a pointer to the class object instead of
 dereferencing the object yourself. But it's a detail to keep in mind.

 A big change in the modern runtime is that classes are completely
 non-fragile, in that you can add a member in a superclass without
 breaking binary compatibility with derived classes. Which means that
 instance variables are accessed differently, by checking a global
 constant to find the right offset (initialized when first loading the
 class). I think the compiler also has to emit that constant that the
 runtime will initialize.

 Another big change is exception handling which now piggyback on the C++
 exception mechanism instead of using the inefficient longjump
 implementation of the previous runtime.

 There's an optimized path for calling certain methods using a virtual
 table, but we can skip that in a first release as it's an optimisation
 (objc_msgSend still work fine in every case).

 Beside that, they changed all the section names for the binary output,
 and probably did a some alterations to the binary structure I'm
 forgetting right now.

What I actually was asking is if there's any difference in the 32bit modern runtime as used by iOS and the 64bit modern runtime? Except for the usual differences that exists in C. -- /Jacob Carlborg
Dec 04 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-04 15:08:23 +0000, Jacob Carlborg <doob me.com> said:

 What I actually was asking is if there's any difference in the 32bit 
 modern runtime as used by iOS and the 64bit modern runtime? Except for 
 the usual differences that exists in C.

Nothing different from the compiler perspective, that I know of. The modern runtime is pretty much the same everywhere. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Dec 04 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-04 17:23, Michel Fortin wrote:

 Nothing different from the compiler perspective, that I know of. The
 modern runtime is pretty much the same everywhere.

Ok, thanks. -- /Jacob Carlborg
Dec 04 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-03 17:55, Manu wrote:

 C++ support in D is 'not complete', but what's there now is still very
 important and not considered a bad partial feature to have.
 I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
 maybe it's worth it in the same sense?
 OSX and iOS are 2 of the most popular platforms on earth. The mobile
 space is probably the most important prospective target for D.
 I can't comment on the state it's in. But if what's there is solid and
 useful like the current C++ support, then it's an important start...?

I agree but Michel has a point as well. Walter, I think it was, has also said that D will never have complete support for C++ because that will require to build in a C++ compiler in the D compiler. That's not something we would like to do. Objective-C, on the other hand, would be much more realistic to add complete support for. You can always help if you like :) -- /Jacob Carlborg
Dec 04 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-04 10:12, Iain Buclaw wrote:

 Forget templates and everything else...

Then it's not complete, just as I said. -- /Jacob Carlborg
Dec 04 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--001a11c20e581bfc2a04ec510593
Content-Type: text/plain; charset=UTF-8

* ARC
* rvalue -> ref
* virtual-by-default
* GC improvements
* AA fixes


On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

--001a11c20e581bfc2a04ec510593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>* ARC</div>* rvalue -&gt; ref<div>* virtual-by-defaul= t</div><div>* GC improvements</div><div>* AA fixes<br></div><div><div class= =3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><div class=3D"gma= il_quote"> On 29 November 2013 07:01, Fra <span dir=3D"ltr">&lt;<a href=3D"mailto:Fra = b.it" target=3D"_blank">Fra b.it</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Personally I would love to see this old issue finally implemented/fixed:<br=

<a href=3D"https://d.puremagic.com/issues/show_bug.cgi?id=3D6083" target=3D= "_blank">https://d.puremagic.com/<u></u>issues/show_bug.cgi?id=3D6083</a><b= r> <br> What would your choice be?<br> </blockquote></div><br></div></div></div> --001a11c20e581bfc2a04ec510593--
Nov 29 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/29/13 5:43 AM, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes

These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues. Andrei
Nov 29 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/30/13 2:12 AM, Jason den Dulk wrote:
 On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote:
 These are good themes but a conversation with one of the bountysource
 founders revealed to me that smaller, precise tasks for moderate
 amounts tend to do better than large projects that are only partially
 specified, even for large amounts.

That's because BountySource is only suited to bite-sized tasks. It is not capable of supporting large, complex projects. As an analogy, BountySource may be great to get potholes filled, but incapable of getting a whole motorway or public transport network developed.

It's a reasonable speculation to make, but without evidence it's only this - speculation. What experience are you drawing from? One reason the bountysource founder mentioned was that large tasks tend to be insufficiently specified, which creates trouble (the worker claim task has been completed but the payer disagrees etc).
 We should break each of these down into bite-sized bugzilla issues.

Instead of re-organising the project to suit the model of third-party website services, the D community needs to recognise that H. S. Teoh is right. The project needs an organised team of full time developers complete with team leadership and project management.

Totally. We're just missing the funds... Andrei
Nov 30 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/2/13 4:19 AM, Manu wrote:
 The problem is that virtual is irrevocable. It can't be removed without
 breaking the API

Here we go again. No, that's not the problem. A similar issue goes about final.
, which means it's not possible to optimise a library in
 that way at any time after it has already been released to the wild. The
 converse is not true.

Conversely final makes it impossible tweak behavior after the library has been released in the wild. You could reasonably argue that you care more about performance optimization than tweaking behavior.
 It has also been agreed that there is very little the compiler/optimiser
 can do to help.

Same goes about "virtualizing" final.
 It's a dangerous default,

How is it "dangerous"?
 it's got absolutely nothing to do with "I
 don't want to type final" as you helpfully simplified it. You can type
 'virtual:' at the top, and you're set.

Can't _you_ type 'final:' at the top and be set? Why is it that, to paraphrase a recent crazy twitter flamewar (http://goo.gl/h9NMxK), your Thanksgiving is more important than everybody else's?
 Again, the converse doesn't
 stand, you can't practically type 'final:' at the top since there will
 inevitable by SOME virtual methods.

Group them before the final: or go through the trouble of typing final { ... }.
 We can spin off another thread if you like, or you can read through the
 old ones. I don't think it's going to go any further than the other
 threads already did.

We'll see. If I learned anything from the past, is this has just restarted. Andrei
Dec 02 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/2/13 5:30 PM, Manu wrote:
 On 3 December 2013 08:43, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 12/2/13 4:19 AM, Manu wrote:

         The problem is that virtual is irrevocable. It can't be removed
         without
         breaking the API


     Here we go again. No, that's not the problem. A similar issue goes
     about final.


 You can safely add virtual to a function where it wasn't previously
 present without breaking code.

If not breaking code is something of value to you, you should appreciate that final-by-default would break a bunch of code. Andrei
Dec 02 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Namespace" <rswhite4 googlemail.com> wrote in message 
news:ixafkrtzclqsrvtsovut forum.dlang.org...
 The first step is to introduce a virtual keyword to avoid the "grouping" 
 of your methods in final blocks. If the next step comes and change from 
 virtual by default to final by default is another matter and should be 
 discussed somewhere else after virtual was introduced.

Yeah. https://github.com/D-Programming-Language/dmd/pull/2895
Dec 03 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-03 02:30, Manu wrote:

 With virtual-by-default, there is strong tendency to leave it in it's
 default state (everything virtual) because it 'just works', and there's
 no warnings or compile errors to remind you what you've committed to.

I showed how you can get "compile errors" for this with some UDA's, CTFE and a minor modification to druntime. I know that's not optimal, but it has to be better than nothing at all. -- /Jacob Carlborg
Dec 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2fa06192f4d04ec515d9e
Content-Type: text/plain; charset=UTF-8

On 29 November 2013 23:27, Jacob Carlborg <doob me.com> wrote:

 On 2013-11-28 22:01, Fra wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

Binary compatibility with Objective-C: http://michelf.ca/projects/d-objc/

I've been very excited about this for a long time... why is it sitting in limbo? How is the implementation? Is there a reason nobody seems to be actually considering it for inclusion? OSX/iOS are 2 very important platforms, and I too would really love to see movement on this work. --001a11c2fa06192f4d04ec515d9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 9 November 2013 23:27, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mail= to:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 2013-11-28 22:01, Fra wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Personally I would love to see this old issue finally implemented/fixed:<br=

<a href=3D"https://d.puremagic.com/issues/show_bug.cgi?id=3D6083" target=3D= "_blank">https://d.puremagic.com/<u></u>issues/show_bug.cgi?id=3D6083</a><b= r> <br> What would your choice be?<br> </blockquote> <br></div></div> Binary compatibility with Objective-C:<br> <br> <a href=3D"http://michelf.ca/projects/d-objc/" target=3D"_blank">http://mic= helf.ca/projects/d-<u></u>objc/</a></blockquote><div><br></div><div>I&#39;v= e been very excited about this for a long time... why is it sitting in limb= o?</div> <div>How is the implementation? Is there a reason nobody seems to be actual= ly considering it for inclusion?</div><div>OSX/iOS are 2 very important pla= tforms, and I too would really love to see movement on this work.</div> </div></div></div> --001a11c2fa06192f4d04ec515d9e--
Nov 29 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 29, 2013 at 01:52:19PM +1100, Daniel Murphy wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.152.1385681675.3242.digitalmars-d puremagic.com...
 One of the most problematic things is that its implementation is
 sprinkled throughout DMD (each bit interacting in intricate ways
 with its surroundings), object_.d (a sort of hybrid half-user,
 half-built-in struct AssociativeArray), and aaA.d (the core runtime
 implementation).  Each of these pieces interact in complex ways with
 each other, and don't always share the same information together.

We can at least fix the hybrid situation: https://github.com/D-Programming-Language/dmd/pull/2856

Excellent!! This will cut my budget in half! ;-) What about the AA value type issue? T -- "Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
Nov 29 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c20afc2652b404ec53c625
Content-Type: text/plain; charset=UTF-8

On 30 November 2013 01:23, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 On 11/29/13 5:43 AM, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes

These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues.

Sure, any tasks that lead towards those goals are within my interest :) --001a11c20afc2652b404ec53c625 Content-Type: text/html; charset=UTF-8 <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 30 November 2013 01:23, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:SeeWebsiteForEmail erdani.org" target="_blank">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/29/13 5:43 AM, Manu wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * ARC<br> * rvalue -&gt; ref<br> * virtual-by-default<br> * GC improvements<br> * AA fixes<br> </blockquote> <br></div> These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts.<br> <br> We should break each of these down into bite-sized bugzilla issues.</blockquote><div><br></div><div>Sure, any tasks that lead towards those goals are within my interest :)</div></div></div></div> --001a11c20afc2652b404ec53c625--
Nov 29 2013
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

https://d.puremagic.com/issues/show_bug.cgi?id=9800 https://d.puremagic.com/issues/show_bug.cgi?id=11530 We seriously need to get debugging output solved! IMHO this is biggest hurdle to mainstream adoption. Devs love debuggers and the current state of affairs using a debugger with D is simply woeful.
Nov 29 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 29, 2013 at 06:13:58PM +0100, Gary Willoughby wrote:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
Personally I would love to see this old issue finally
implemented/fixed:
There can be only one alias this.
https://d.puremagic.com/issues/show_bug.cgi?id=6083

What would your choice be?

https://d.puremagic.com/issues/show_bug.cgi?id=9800 https://d.puremagic.com/issues/show_bug.cgi?id=11530 We seriously need to get debugging output solved! IMHO this is biggest hurdle to mainstream adoption. Devs love debuggers and the current state of affairs using a debugger with D is simply woeful.

+1. I have to admit I rarely use a debugger, but just this week, I had to debug a few segfaults in my D code, and trying to use gdb with a dmd-compiled executable was very painful. The debugger seemed to just jump about with only an approximate idea of where the code was actually going, and half the symbols weren't recognized. I had to resort to writeln debugging to track down the problem. I can see how someone used to a debugger would throw up their hands at this situation. T -- Never trust an operating system you don't have source for! -- Martin Schulze
Nov 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 29 November 2013 at 00:52:27 UTC, Dicebot wrote:
 Nice game "guess linked bug by poster nickname" :)

mine quite works
Nov 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 29 November 2013 at 17:14:00 UTC, Gary Willoughby 
wrote:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

https://d.puremagic.com/issues/show_bug.cgi?id=9800 https://d.puremagic.com/issues/show_bug.cgi?id=11530 We seriously need to get debugging output solved! IMHO this is biggest hurdle to mainstream adoption. Devs love debuggers and the current state of affairs using a debugger with D is simply woeful.

++1++
Nov 29 2013
prev sibling next sibling parent "Nick" <nmsmith65 gmail.com> writes:
On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu 
wrote:
 On 11/29/13 5:43 AM, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes

These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues. Andrei

A bite-sized GC-related improvement is the nogc attribute I've been craving for for quite some time. See: https://d.puremagic.com/issues/show_bug.cgi?id=5219 If I had money, I'd be putting it on this for sure. For system and game programmers it's a godsend, and it will put some C++ fanatics at ease with D's GC. With this feature I can protect the critical sections of my code with a firm guarantee that I won't see any unexpected activity from the GC.
Nov 29 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
--001a113382b4921af804ec60ebbc
Content-Type: text/plain; charset=ISO-8859-1

On Nov 30, 2013 3:01 AM, "Nick" <nmsmith65 gmail.com> wrote:
 On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote:
 On 11/29/13 5:43 AM, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes

These are good themes but a conversation with one of the bountysource


tend to do better than large projects that are only partially specified, even for large amounts.
 We should break each of these down into bite-sized bugzilla issues.


 Andrei

A bite-sized GC-related improvement is the nogc attribute I've been

https://d.puremagic.com/issues/show_bug.cgi?id=5219
 If I had money, I'd be putting it on this for sure. For system and game

D's GC. With this feature I can protect the critical sections of my code with a firm guarantee that I won't see any unexpected activity from the GC. But how do you expect this to be implemented? Implicitly putting GC.disable/GC.enable at the prologue / epilogue of a function? Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a113382b4921af804ec60ebbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Nov 30, 2013 3:01 AM, &quot;Nick&quot; &lt;<a href=3D"mailto:nmsmith65 g= mail.com">nmsmith65 gmail.com</a>&gt; wrote:<br> &gt;<br> &gt; On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote= :<br> &gt;&gt;<br> &gt;&gt; On 11/29/13 5:43 AM, Manu wrote:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; * ARC<br> &gt;&gt;&gt; * rvalue -&gt; ref<br> &gt;&gt;&gt; * virtual-by-default<br> &gt;&gt;&gt; * GC improvements<br> &gt;&gt;&gt; * AA fixes<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; These are good themes but a conversation with one of the bountysou= rce founders revealed to me that smaller, precise tasks for moderate amount= s tend to do better than large projects that are only partially specified, = even for large amounts.<br> &gt;&gt;<br> &gt;&gt; We should break each of these down into bite-sized bugzilla issues= .<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; Andrei<br> &gt;<br> &gt;<br> &gt; A bite-sized GC-related improvement is the nogc attribute I&#39;ve be= en craving for for quite some time. See: <a href=3D"https://d.puremagic.com= /issues/show_bug.cgi?id=3D5219">https://d.puremagic.com/issues/show_bug.cgi= ?id=3D5219</a><br> &gt;<br> &gt; If I had money, I&#39;d be putting it on this for sure. For system and= game programmers it&#39;s a godsend, and it will put some C++ fanatics at = ease with D&#39;s GC. With this feature I can protect the critical sections= of my code with a firm guarantee that I won&#39;t see any unexpected activ= ity from the GC.</p> <p>But how do you expect this to be implemented? Implicitly putting GC.disa= ble/GC.enable at the prologue / epilogue of a function?</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --001a113382b4921af804ec60ebbc--
Nov 30 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Iain Buclaw:

 But how do you expect this to be implemented? Implicitly putting
 GC.disable/GC.enable at the prologue / epilogue of a function?

The point of annotations like nogc or noheap is not to disable the GC, but to statically disallow its usage transitively inside a function. Bye, bearophile
Nov 30 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 30 November 2013 at 02:57:54 UTC, Nick wrote:
 On Friday, 29 November 2013 at 15:23:13 UTC, Andrei 
 Alexandrescu wrote:
 On 11/29/13 5:43 AM, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes

These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts. We should break each of these down into bite-sized bugzilla issues. Andrei

A bite-sized GC-related improvement is the nogc attribute I've been craving for for quite some time. See: https://d.puremagic.com/issues/show_bug.cgi?id=5219 If I had money, I'd be putting it on this for sure. For system and game programmers it's a godsend, and it will put some C++ fanatics at ease with D's GC. With this feature I can protect the critical sections of my code with a firm guarantee that I won't see any unexpected activity from the GC.

DIP46 can help: http://wiki.dlang.org/DIP46 Quote: A further observation is that class GC has virtual functions in it. This opens up the possibility of doing a gc_push() with a different GC. Two possibilities come to mind: 1. Allocate-but-never-free, like DMD does. This would be very fast. 2. Assert-on-any-allocation, used for code that wants to be "nogc". This avoids the complexity of adding a "nogc" attribute to D. More discussion of "nogc": https://github.com/D-Programming-Language/druntime/pull/493
Nov 30 2013
prev sibling next sibling parent "Nick" <nmsmith65 gmail.com> writes:
On Saturday, 30 November 2013 at 08:42:11 UTC, Iain Buclaw wrote:
 But how do you expect this to be implemented? Implicitly putting
 GC.disable/GC.enable at the prologue / epilogue of a function?

The purpose of nogc is not to prevent the GC from running when you make an allocation, it's to have compile-time assurance that the function (and any other functions it calls) won't set off any GC allocations in the first place. It should work the same way as nothrow which guarantees a function won't throw an exception.
Nov 30 2013
prev sibling next sibling parent "Jason den Dulk" <public2 jasondendulk.com> writes:
On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu 
wrote:
 On 11/29/13 5:43 AM, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes

These are good themes but a conversation with one of the bountysource founders revealed to me that smaller, precise tasks for moderate amounts tend to do better than large projects that are only partially specified, even for large amounts.

That's because BountySource is only suited to bite-sized tasks. It is not capable of supporting large, complex projects. As an analogy, BountySource may be great to get potholes filled, but incapable of getting a whole motorway or public transport network developed.
 We should break each of these down into bite-sized bugzilla 
 issues.

Instead of re-organising the project to suit the model of third-party website services, the D community needs to recognise that H. S. Teoh is right. The project needs an organised team of full time developers complete with team leadership and project management. Regards Jason
Nov 30 2013
prev sibling next sibling parent "Nick" <nmsmith65 gmail.com> writes:
On Saturday, 30 November 2013 at 09:28:54 UTC, Namespace wrote:
 DIP46 can help:
 http://wiki.dlang.org/DIP46

 Quote:
 A further observation is that class GC has virtual functions in 
 it. This opens up the possibility of doing a gc_push() with a 
 different GC. Two possibilities come to mind:
 1. Allocate-but-never-free, like DMD does. This would be very 
 fast.
 2. Assert-on-any-allocation, used for code that wants to be 
 "nogc". This avoids the complexity of adding a "nogc" attribute 
 to D. More discussion of "nogc": 
 https://github.com/D-Programming-Language/druntime/pull/493

While having the ability to create 'tossable' regions of garbage-collected memory would be fantastic (I would really love to see that implemented), it does not completely solve the problem that nogc (and noheap) tries to solve. The point of nogc is to have the compiler check for you that you didn't accidentally make allocations. It works on the presumption that you were trying to write allocation-free code. The assert-on-allocation idea from DIP46 won't achieve this either, as it leaves it to chance whether or not the execution of your code will reach an allocating call. There's no guarantee there.
Nov 30 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
--047d7b6dc0bce2c84204ec634d06
Content-Type: text/plain; charset=ISO-8859-1

On Nov 30, 2013 9:30 AM, "bearophile" <bearophileHUGS lycos.com> wrote:
 Iain Buclaw:


 But how do you expect this to be implemented? Implicitly putting
 GC.disable/GC.enable at the prologue / epilogue of a function?

The point of annotations like nogc or noheap is not to disable the GC,


Ok, but what you describe is a different meaning to "no unexpected activity from the GC in critical sections". I'll have to double check, but do we still have a sort of global lock system in the GC for handling multiple threads? Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7b6dc0bce2c84204ec634d06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>On Nov 30, 2013 9:30 AM, &quot;bearophile&quot; &lt;<a href=3D"mailto:be= arophileHUGS lycos.com">bearophileHUGS lycos.com</a>&gt; wrote:<br> &gt;<br> &gt; Iain Buclaw:<br> &gt;<br> &gt;<br> &gt;&gt; But how do you expect this to be implemented? Implicitly putting<b= r> &gt;&gt; GC.disable/GC.enable at the prologue / epilogue of a function?<br> &gt;<br> &gt;<br> &gt; The point of annotations like nogc or noheap is not to disable the G= C, but to statically disallow its usage transitively inside a function.<br> &gt;</p> <p>Ok,=A0 but what you describe is a different meaning to &quot;no unexpect= ed activity from the GC in critical sections&quot;. I&#39;ll have to double= check, but do we still have a sort of global lock system in the GC for han= dling multiple threads?</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --047d7b6dc0bce2c84204ec634d06--
Nov 30 2013
prev sibling next sibling parent "Nick" <nmsmith65 gmail.com> writes:
On Saturday, 30 November 2013 at 11:33:06 UTC, Iain Buclaw wrote:
 On Nov 30, 2013 9:30 AM, "bearophile" 
 <bearophileHUGS lycos.com> wrote:
 The point of annotations like  nogc or  noheap is not to 
 disable the GC,

function.

Ok, but what you describe is a different meaning to "no unexpected activity from the GC in critical sections". I'll have to double check, but do we still have a sort of global lock system in the GC for handling multiple threads? Regards

Ah, yes. When we have multiple threads running nogc won't guarantee "no unexpected activity" alone, that is true. It can however, be combined with the non-suspendable threads feature that was proposed a few months ago here: https://github.com/D-Programming-Language/druntime/pull/493 I would think it would be possible to force a non-suspendable thread to accept only a nogc function as an entry point, too, if the thread's suspendability is fixed at creation. These two enhancements plus DIP46 would together give D programmers some serious freedom with respect to working with the GC. Not only would it greatly simplify GC-free programming, but it would allow for (trustworthy) hybrid GC/manual memory management for applications which need to have total control over only specific sections of code or specific threads.
Nov 30 2013
prev sibling next sibling parent "Jason den Dulk" <public2 jasondendulk.com> writes:
On Saturday, 30 November 2013 at 11:37:24 UTC, Andrei 
Alexandrescu wrote:
 On 11/30/13 2:12 AM, Jason den Dulk wrote:
 Instead of re-organising the project to suit the model of 
 third-party
 website services, the D community needs to recognise that H. 
 S. Teoh is
 right. The project needs an organised team of full time 
 developers
 complete with team leadership and project management.

Totally. We're just missing the funds...

Not to criticise your current efforts, but might I suggest you shift some emphasis to obtaining sponsorship? I may be wrong, but it appears that this is something D seriously lacks. All major open source projects have financial backing. Organisations like the Linux Foundation, the Mozilla Foundation, the Apache Foundation and others exist in part to raise money for the projects they look after. If D has serious aspirations of "making it", it should have the same. Regards Jason
Nov 30 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Fra:

 What would your choice be?

Some I like: - Strongly typed array indexes (this gives safer and more clear code, and faster code in debug builds). - More tuple syntax (that allows shorter, more handy and readable code). - 596 switch on structs + unapply. - 3999 Enum equality to an int. - 4085 Steps toward a static foreach. - 5409 Disallow (!x & y). - 5713 Broken final switch on ints. - 9850 Compiler support to implement efficient safe integrals. Bye, bearophile
Nov 30 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 30, 2013 at 05:47:37PM +1100, Daniel Murphy wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.165.1385740581.3242.digitalmars-d puremagic.com...

 What about the AA value type issue?

I don't think we do anything. Let the builtin AA type be simple, slow, and reliable. When performance matters, use a library type you can customize.

Sorry, I meant, what to do about aaA.d not being passed the TypeInfo of AA values. This causes things like aa[key]++ to produce wrong results when the value's .init isn't binary zero. T -- Life is complex. It consists of real and imaginary parts. -- YHL
Nov 30 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 30, 2013 at 02:39:10PM +0100, Jason den Dulk wrote:
 On Saturday, 30 November 2013 at 11:37:24 UTC, Andrei Alexandrescu
 wrote:
On 11/30/13 2:12 AM, Jason den Dulk wrote:
Instead of re-organising the project to suit the model of
third-party website services, the D community needs to recognise
that H. S.  Teoh is right. The project needs an organised team of
full time developers complete with team leadership and project
management.

Totally. We're just missing the funds...

Not to criticise your current efforts, but might I suggest you shift some emphasis to obtaining sponsorship? I may be wrong, but it appears that this is something D seriously lacks. All major open source projects have financial backing. Organisations like the Linux Foundation, the Mozilla Foundation, the Apache Foundation and others exist in part to raise money for the projects they look after. If D has serious aspirations of "making it", it should have the same.

Seeing how much we raised for DConf last year through kickstarter, I wonder if it might be possible to use kickstarter to raise funds for hiring a team of developers to work full-time on D? T -- Caffeine underflow. Brain dumped.
Nov 30 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:
 Seeing how much we raised for DConf last year through 
 kickstarter, I wonder if it might be possible to use
 kickstarter to raise funds for hiring a team of developers
 to work full-time on D?

Aye, And since D rox it might not even be terribly expensive - I'd be willing to devote half-time to D (~15-25 hours / week) at the community's direction for $1,500 / month, give or take. (And that's actually enough to cover my bills, so a good chunk of that other half time might also go to D! But I can't devote full time at a discount.)
Nov 30 2013
prev sibling next sibling parent "Nick" <nmsmith65 gmail.com> writes:
On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:
 Seeing how much we raised for DConf last year through 
 kickstarter, I
 wonder if it might be possible to use kickstarter to raise 
 funds for
 hiring a team of developers to work full-time on D?

Even as a student, I'd be happy to throw money at D, if someone could give me a good reason to. I really want to see D succeed. I'm just not rich enough to be putting $20 bounties up on (multiple) individual bugs. I like the idea of a Kickstarter, if it could be done effectively. It would need some planning out.
Nov 30 2013
prev sibling next sibling parent "Jason den Dulk" <public2 jasondendulk.com> writes:
On Saturday, 30 November 2013 at 23:13:05 UTC, Nick wrote:
 On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:
 Seeing how much we raised for DConf last year through 
 kickstarter, I
 wonder if it might be possible to use kickstarter to raise 
 funds for
 hiring a team of developers to work full-time on D?

Even as a student, I'd be happy to throw money at D, if someone could give me a good reason to. I really want to see D succeed. I'm just not rich enough to be putting $20 bounties up on (multiple) individual bugs. I like the idea of a Kickstarter, if it could be done effectively. It would need some planning out.

The D decision makers would have to decide what would work best, but setting up a non-profit organisation, and using that to raise funds is the standard model, and is known to work. I can contribute a small amount each month, and I'm sure other D enthusiasts could do the same. 170 sponsors contributing an average of $50 a month would pay for 1 full time developer and $50/hr at 38 hrs/wk. As for a good reason, the success of D is that reason. As I mentioned in an earlier post, all successful projects (AFAIK) have financial backing, and projects that rely purely on volunteer efforts tend to die of asphyxiation. Regards Jason
Nov 30 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b41c0ba91a76504ec6ef8cb
Content-Type: text/plain; charset=UTF-8

On 1 December 2013 10:54, Jason den Dulk <public2 jasondendulk.com> wrote:

 On Saturday, 30 November 2013 at 23:13:05 UTC, Nick wrote:

 On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:

 Seeing how much we raised for DConf last year through kickstarter, I
 wonder if it might be possible to use kickstarter to raise funds for
 hiring a team of developers to work full-time on D?

Even as a student, I'd be happy to throw money at D, if someone could give me a good reason to. I really want to see D succeed. I'm just not rich enough to be putting $20 bounties up on (multiple) individual bugs. I like the idea of a Kickstarter, if it could be done effectively. It would need some planning out.

The D decision makers would have to decide what would work best, but setting up a non-profit organisation, and using that to raise funds is the standard model, and is known to work. I can contribute a small amount each month, and I'm sure other D enthusiasts could do the same. 170 sponsors contributing an average of $50 a month would pay for 1 full time developer and $50/hr at 38 hrs/wk.

I wonder what that would do to the existing contributors though? I have a suspicion that guys like Kenji and Daniel Murphy already spend something close to 'full time' hours on D voluntarily. --047d7b41c0ba91a76504ec6ef8cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= December 2013 10:54, Jason den Dulk <span dir=3D"ltr">&lt;<a href=3D"mailt= o:public2 jasondendulk.com" target=3D"_blank">public2 jasondendulk.com</a>&= gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On S= aturday, 30 November 2013 at 23:13:05 UTC, Nick wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Seeing how much we raised for DConf last year through kickstarter, I<br> wonder if it might be possible to use kickstarter to raise funds for<br> hiring a team of developers to work full-time on D?<br> </blockquote> <br> Even as a student, I&#39;d be happy to throw money at D, if someone could g= ive me a good reason to. I really want to see D succeed. I&#39;m just not r= ich enough to be putting $20 bounties up on (multiple) individual bugs.<br> <br> I like the idea of a Kickstarter, if it could be done effectively. It would= need some planning out.<br> </blockquote> <br></div></div> The D decision makers would have to decide what would work best, but settin= g up a non-profit organisation, and using that to raise funds is the standa= rd model, and is known to work. I can contribute a small amount each month,= and I&#39;m sure other D enthusiasts could do the same. 170 sponsors contr= ibuting an average of $50 a month would pay for 1 full time developer and $= 50/hr at 38 hrs/wk.<br> </blockquote><div><br></div><div>I wonder what that would do to the existin= g contributors though?</div><div>I have a suspicion that guys like Kenji an= d Daniel Murphy already spend something close to &#39;full time&#39; hours = on D voluntarily.</div> </div></div></div> --047d7b41c0ba91a76504ec6ef8cb--
Nov 30 2013
prev sibling next sibling parent "CJS" <Prometheus85 hotmail.com> writes:
 I wonder what that would do to the existing contributors though?
 I have a suspicion that guys like Kenji and Daniel Murphy 
 already spend
 something close to 'full time' hours on D voluntarily.

An interesting comparison is some of the projects in the scientific python ecosystem. Important stuff that a lot of scientists, both in academia and industry, use on a daily basis. For a long time they've struggled with how to pay coders to deal with maintenance/compatibility of important foundational code bases. This is a difficult problem since the users are largely python programmers but, for example, some of the packages are mostly low-level C extension modules with some code generation tools (so you need to know C, the C-Python API, and how the packages generate C code) and additionally specialized open-source libraries in C and Fortran. Other packages are friendlier, but to get speed they're still in cython, which requires some C knowledge. I think matplotlib, scikit-learn, ipython, and numpy/scipy get the most money/love-and-attention. And each has their own core contributor groups and money pools. Recently it's gotten more organized with the NumFocus (http://numfocus.org/) non-profit. It's an umbrella organization for supporting scientific python efforts across the spectrum of available libraries. I'm sure anyone who was interested in doing something similar for D could ask some of the NumFocus folks how they setup their organization, and then the D community could similarly have a focal point for gathering funds which could be used for various maintenance and enhancements in the D ecosystem. I think the current state involves a fair amount of funding for high contributors, especially student contributors (who are usually in need of funds) to take anywhere between a quarter and a year to just work on maintenance issues, bug-fixing, and some high priority enhancements.
Nov 30 2013
prev sibling next sibling parent "sclytrack" <sclytrack fake.com> writes:
Re: If you had money to place for a bounty, what would you choose?

Official debian packages for gdc, derelict, gtkd, vibed.
Dec 01 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
--089e0149d2c4f5a28a04ec75f595
Content-Type: text/plain; charset=ISO-8859-1

On Dec 1, 2013 8:10 AM, "sclytrack" <sclytrack fake.com> wrote:
 Re: If you had money to place for a bounty, what would you choose?

 Official debian packages for gdc, derelict, gtkd, vibed.

The gdc packages in Debian are official. :) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --089e0149d2c4f5a28a04ec75f595 Content-Type: text/html; charset=ISO-8859-1 <p><br> On Dec 1, 2013 8:10 AM, &quot;sclytrack&quot; &lt;<a href="mailto:sclytrack fake.com">sclytrack fake.com</a>&gt; wrote:<br> &gt;<br> &gt;<br> &gt; Re: If you had money to place for a bounty, what would you choose?<br> &gt;<br> &gt; Official debian packages for gdc, derelict, gtkd, vibed.</p> <p>The gdc packages in Debian are official. :)</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) = (c &amp; 0x0f) + &#39;0&#39;;</p> --089e0149d2c4f5a28a04ec75f595--
Dec 01 2013
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


I hope virtual-by-default never gets approved. I read DIP51 and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...
Dec 02 2013
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

1) C++ namespace support 2) AA fixes 3) std.lexer in Phobos. 4) curl out of Phobos. Replaced by std.net.http package would be an extra plus. And yes, I know that curl is more than just a http client, all other supported protocols would go into std.net eventually.
Dec 02 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/2/13 1:36 AM, Dejan Lekic wrote:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

1) C++ namespace support 2) AA fixes 3) std.lexer in Phobos. 4) curl out of Phobos. Replaced by std.net.http package would be an extra plus. And yes, I know that curl is more than just a http client, all other supported protocols would go into std.net eventually.

Which of these have bugzilla entries associated with them? Andrei
Jan 10 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 2 December 2013 09:33, Dejan Lekic <dejan.lekic gmail.com> wrote:
 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


I hope virtual-by-default never gets approved. I read DIP51 and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

Come to Dconf 2014 and we'll have another round of talks over beer. :-)
Dec 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 2 December 2013 at 09:33:02 UTC, Dejan Lekic wrote:
 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


I hope virtual-by-default never gets approved. I read DIP51 and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

So final by default is preferable. And (AFAIK) it is already approved by Walter: http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq forum.dlang.org?page=28#post-koqkhc:244nn:241:40digitalmars.com So let us thank Manu and let us hope it comes with 2.065!
Dec 02 2013
prev sibling next sibling parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 2013-12-02 12:14, Namespace wrote:
 On Monday, 2 December 2013 at 09:33:02 UTC, Dejan Lekic wrote:
 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


I hope virtual-by-default never gets approved. I read DIP51 and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

by default is preferable.

Also, while a JIT may be able to devirtualize some functions, D compilers do not have that privilege.
 So let us thank Manu and let us hope it comes with 2.065!

Indeed. -- Simen
Dec 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11333a4e7a0b8804ec8c2f6c
Content-Type: text/plain; charset=UTF-8

On 2 December 2013 19:33, Dejan Lekic <dejan.lekic gmail.com> wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

  Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

There's been endless discussions on the topic. There was a link to a thread with loads of discussion. The problem is that virtual is irrevocable. It can't be removed without breaking the API, which means it's not possible to optimise a library in that way at any time after it has already been released to the wild. The converse is not true. It has also been agreed that there is very little the compiler/optimiser can do to help. It's a dangerous default, it's got absolutely nothing to do with "I don't want to type final" as you helpfully simplified it. You can type 'virtual:' at the top, and you're set. Again, the converse doesn't stand, you can't practically type 'final:' at the top since there will inevitable by SOME virtual methods. We can spin off another thread if you like, or you can read through the old ones. I don't think it's going to go any further than the other threads already did. --001a11333a4e7a0b8804ec8c2f6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= December 2013 19:33, Dejan Lekic <span dir=3D"ltr">&lt;<a href=3D"mailto:d= ejan.lekic gmail.com" target=3D"_blank">dejan.lekic gmail.com</a>&gt;</span=
 wrote:<br>

x #ccc solid;padding-left:1ex"><div class=3D"im">On Friday, 29 November 201= 3 at 13:44:10 UTC, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> * ARC<br> * rvalue -&gt; ref<br> * virtual-by-default<br> * GC improvements<br> * AA fixes<br> <br> <br></div><div class=3D"im"> On 29 November 2013 07:01, Fra &lt;<a href=3D"mailto:Fra b.it" target=3D"_b= lank">Fra b.it</a>&gt; wrote:<br> <br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Personally I would love to see this old issue finally implemented/fixed:<br=

<a href=3D"https://d.puremagic.com/issues/show_bug.cgi?id=3D6083" target=3D= "_blank">https://d.puremagic.com/<u></u>issues/show_bug.cgi?id=3D6083</a><b= r> <br> What would your choice be?<br> </blockquote></div></div></blockquote> <br> I hope virtual-by-default never gets approved. I read DIP51 and quite frank= ly I am not convinced at all. It is basically &quot;I do not want to put fi= nal in front of my methods. Well, I do not want to put virtual in front of = my methods... But this is perhaps something for another discussion...<br> </blockquote></div><br></div><div class=3D"gmail_extra">There&#39;s been en= dless discussions on the topic. There was a link to a thread with loads of = discussion.</div><div class=3D"gmail_extra">The problem is that virtual is = irrevocable. It can&#39;t be removed without breaking the API, which means = it&#39;s not possible to optimise a library in that way at any time after i= t has already been released to the wild. The converse is not true.</div> <div class=3D"gmail_extra">It has also been agreed that there is very littl= e the compiler/optimiser can do to help.</div><div class=3D"gmail_extra">It= &#39;s a dangerous default, it&#39;s got absolutely nothing to do with &quo= t;I don&#39;t want to type final&quot; as you helpfully simplified it. You = can type &#39;virtual:&#39; at the top, and you&#39;re set. Again, the conv= erse doesn&#39;t stand, you can&#39;t practically type &#39;final:&#39; at = the top since there will inevitable by SOME virtual methods.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">We can spin= off another thread if you like, or you can read through the old ones. I do= n&#39;t think it&#39;s going to go any further than the other threads alrea= dy did.</div> </div> --001a11333a4e7a0b8804ec8c2f6c--
Dec 02 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 December 2013 at 11:14:58 UTC, Namespace wrote:
 final by default is far more efficient than virtual by default. 
 So final by default is preferable.

The *whole point* of classes is to have virtual functions. If you don't want them, don't write class methods! Use structs or UFCS instead. Perhaps a counter argument is that the whole point of *interfaces* is virtual functions, and classes just implement them and thus ought to be final, if you want virtual stuff go through the interface. But, regardless, I think the real problem here isn't virtual by default. The real problem is there's things written as class methods that really shouldn't me methods at all. The ideal "method" is actually a UFCS function that operates on the interface, without touching any private state at all. Next best is a UFCS function that works on the class and needs private state. The only time it, at least ideally speaking, should be in the class itself is if it has something to do with implementing interfaces. And that means virtual generally makes sense.
Dec 02 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 2 December 2013 12:17, Simen Kjrs <simen.kjaras gmail.com> wrote:
 On 2013-12-02 12:14, Namespace wrote:
 On Monday, 2 December 2013 at 09:33:02 UTC, Dejan Lekic wrote:
 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:
 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


I hope virtual-by-default never gets approved. I read DIP51 and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

final by default is far more efficient than virtual by default. So final by default is preferable.

Also, while a JIT may be able to devirtualize some functions, D compilers do not have that privilege.

There's actually some development being brewed up in GCC (and I've heard ushers from LLVM too) around the ability to devirtualise functions at compile time if it is able to prove that there is only one place where the call can go based off the information built up about type inheritance and basetypes.
Dec 02 2013
prev sibling next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 What would your choice be?

Personally I'd like to see this one fixed: http://d.puremagic.com/issues/show_bug.cgi?id=5710 In fact I tried to cash in on one of the early back-end bugs to shift the bounty to it, but I was beat to the punch by ~10 minutes (had to do other things before finalizing/re-reviewing my commit.)
Dec 02 2013
prev sibling next sibling parent "Momo Zilla" <MZ yahoo.mx> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

Personnaly I think there is something incoherant with "this" and "pointer to this", it often leads to cast "this" as a pointer ( e.g: return cast(void*) this: for the outside world.) There's something not quite clear, not well documented about this, which leads to an incoherant cast(type hint for the compilo).
Dec 02 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Monday, 2 December 2013 at 22:43:44 UTC, Andrei Alexandrescu 
wrote:
 We'll see. If I learned anything from the past, is this has 
 just restarted.

I don't have a horse in this race, but I though that this had already been decided, to the satisfaction of Manu? Did anything change after the mentioned thread?
Dec 02 2013
prev sibling next sibling parent "nazriel" <spam dzfl.pl> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

I would support LDC project - so maybe more people would work on it. //*me* wishes he could use LDC with Vibe.d
Dec 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2aa6aefae1404ec973db0
Content-Type: text/plain; charset=UTF-8

On 3 December 2013 08:43, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 wrote:

 On 12/2/13 4:19 AM, Manu wrote:

 The problem is that virtual is irrevocable. It can't be removed without
 breaking the API

Here we go again. No, that's not the problem. A similar issue goes about final.

You can safely add virtual to a function where it wasn't previously present without breaking code. , which means it's not possible to optimise a library in
 that way at any time after it has already been released to the wild. The
 converse is not true.

Conversely final makes it impossible tweak behavior after the library has been released in the wild. You could reasonably argue that you care more about performance optimization than tweaking behavior.

If you're making the kind of library where you want everything to be overridable, writing 'virtual:' at the top is easy. Do that, you're happy, and your intentions are made explicit, and there's also no room for error. It's nowhere near as simple approaching from the other angle, extremely prone to human error, and if a mistake is made, it it's a breaking change any time you want to fix it. It has also been agreed that there is very little the compiler/optimiser
 can do to help.

Same goes about "virtualizing" final.

What? It's a dangerous default,

How is it "dangerous"?

Because it's a breaking change. You can't add final after it's ever seen the light of day. No code is fully optimal after revision 0.01b, people always make mistakes, or react to feedback. Library authors are always very apprehensive to make breaking changes to their libs, so it's very hard to get things fixed. It also requires bumping the major version with semantic versioning to make performance tweaks, and library authors don't like to do that if they can avoid it. It creates a situation where it's very hard to get fixes. it's got absolutely nothing to do with "I
 don't want to type final" as you helpfully simplified it. You can type
 'virtual:' at the top, and you're set.

Can't _you_ type 'final:' at the top and be set? Why is it that, to paraphrase a recent crazy twitter flamewar (http://goo.gl/h9NMxK), your Thanksgiving is more important than everybody else's?

No. Classes have virtual functions, that's the point. So you have to micro manage it. There is not much sense in a class with 'final:', there is sense in a class with 'virtual:', if you want to write your code that way, and the intention is made explicit, which is rarely a bad thing. With virtual-by-default, there is strong tendency to leave it in it's default state (everything virtual) because it 'just works', and there's no warnings or compile errors to remind you what you've committed to. What I mean is, the author of the code never deliberately made a _choice_, but they have (probably unknowingly) made a strong commitment. If you're a library author, you can't correct it later without bumping the major version, and risk breaking client code. I don't have thanksgiving; you're welcome to it. I don't see the parallel, I don't consider this a flamewar. Again, the converse doesn't
 stand, you can't practically type 'final:' at the top since there will
 inevitable by SOME virtual methods.

Group them before the final: or go through the trouble of typing final { ... }.

Just type 'virtual:' at the top. Much simpler. --001a11c2aa6aefae1404ec973db0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3= December 2013 08:43, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"= mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail = erdani.org</a>&gt;</span> wrote:<br> </div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex"><div class=3D"im">On 12/2= /13 4:19 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> The problem is that virtual is irrevocable. It can&#39;t be removed without= <br> breaking the API<br> </blockquote> <br></div> Here we go again. No, that&#39;s not the problem. A similar issue goes abou= t final.</blockquote><div><br></div><div>You can safely add virtual to a fu= nction where it wasn&#39;t previously present without breaking code.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> , which means it&#39;s not possible to optimise a library in<br> that way at any time after it has already been released to the wild. The<br=

</blockquote> <br></div> Conversely final makes it impossible tweak behavior after the library has b= een released in the wild. You could reasonably argue that you care more abo= ut performance optimization than tweaking behavior.</blockquote><div><br> </div><div>If you&#39;re making the kind of library where you want everythi= ng to be overridable, writing &#39;virtual:&#39; at the top is easy. Do tha= t, you&#39;re happy, and your intentions are made explicit, and there&#39;s= also no room for error.</div> <div>It&#39;s nowhere near as simple approaching from the other angle, extr= emely prone to human error, and if a mistake is made, it it&#39;s a breakin= g change=C2=A0any time you want to fix it.</div><div><br></div><div><br></d= iv> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> It has also been agreed that there is very little the compiler/optimiser<br=

</blockquote> <br></div> Same goes about &quot;virtualizing&quot; final.</blockquote><div><br></div>= <div>What?</div><div><br></div><div><br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co= lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> It&#39;s a dangerous default,<br> </blockquote> <br></div> How is it &quot;dangerous&quot;?</blockquote><div><br></div><div>Because it= &#39;s a breaking change. You can&#39;t add final after it&#39;s ever seen = the light of day. No code is fully optimal after revision 0.01b, people alw= ays make mistakes, or react to feedback.</div> <div>Library authors are always very apprehensive to make breaking changes = to their libs, so it&#39;s very hard to get things fixed.</div><div>It also= requires bumping the major version with semantic versioning to make perfor= mance tweaks, and library authors don&#39;t like to do that if they can avo= id it. It creates a situation where it&#39;s very hard to get fixes.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> it&#39;s got absolutely nothing to do with &quot;I<br> don&#39;t want to type final&quot; as you helpfully simplified it. You can = type<br> &#39;virtual:&#39; at the top, and you&#39;re set.<br> </blockquote> <br></div> Can&#39;t _you_ type &#39;final:&#39; at the top and be set? Why is it that= , to paraphrase a recent crazy twitter flamewar (<a href=3D"http://goo.gl/h= 9NMxK" target=3D"_blank">http://goo.gl/h9NMxK</a>), your Thanksgiving is mo= re important than everybody else&#39;s?</blockquote> <div><br></div><div>No. Classes have virtual functions, that&#39;s the poin= t. So you have to micro manage it.</div><div>There is not much sense in a c= lass with &#39;final:&#39;, there is sense in a class with &#39;virtual:&#3= 9;, if you want to write your code that way, and the intention is made expl= icit, which is rarely a bad thing.</div> <div><br></div><div>With virtual-by-default, there is strong tendency to le= ave it in it&#39;s default state (everything virtual) because it &#39;just = works&#39;, and there&#39;s no warnings or compile errors to remind you wha= t you&#39;ve committed to.</div> <div>What I mean is, the author of the code never deliberately made a _choi= ce_, but they have (probably unknowingly) made a strong commitment. If you&= #39;re a library author, you can&#39;t correct it later without bumping the= major version, and risk breaking client code.</div> <div><br></div><div>I don&#39;t have thanksgiving; you&#39;re welcome to it= .</div><div>I don&#39;t see the parallel, I don&#39;t consider this a flame= war.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg= b(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Again, the converse doesn&#39;t<br> stand, you can&#39;t practically type &#39;final:&#39; at the top since the= re will<br> inevitable by SOME virtual methods.<br> </blockquote> <br></div> Group them before the final: or go through the trouble of typing final { ..= . }.</blockquote><div><br></div><div>Just type &#39;virtual:&#39; at the to= p. Much simpler.</div></div></div></div> --001a11c2aa6aefae1404ec973db0--
Dec 02 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e0149ccae4d55f004ec99c96b
Content-Type: text/plain; charset=UTF-8

On 3 December 2013 13:14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 wrote:

 On 12/2/13 5:30 PM, Manu wrote:

 On 3 December 2013 08:43, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>

 wrote:

     On 12/2/13 4:19 AM, Manu wrote:

         The problem is that virtual is irrevocable. It can't be removed
         without
         breaking the API


     Here we go again. No, that's not the problem. A similar issue goes
     about final.


 You can safely add virtual to a function where it wasn't previously
 present without breaking code.

If not breaking code is something of value to you, you should appreciate that final-by-default would break a bunch of code.

Only once upon changing the default, and with the opportunity for a controlled deprecation path which clearly communicates with users. Otherwise this remains an ongoing issue forever. --089e0149ccae4d55f004ec99c96b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3= December 2013 13:14, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"= mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail = erdani.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 12/2/13 5:30 PM, Manu w= rote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 3 December 2013 08:43, Andrei Alexandrescu<br></div> &lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeW= ebsiteForEmail erdani.org</a> &lt;mailto:<a href=3D"mailto:SeeWebsiteForEma= il erdani.org" target=3D"_blank">SeeWebsiteForEmail <u></u>erdani.org</a>&g= t;&gt;<div class=3D"im"> <br> wrote:<br> <br> =C2=A0 =C2=A0 On 12/2/13 4:19 AM, Manu wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The problem is that virtual is irrevocable. It = can&#39;t be removed<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 without<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 breaking the API<br> <br> <br> =C2=A0 =C2=A0 Here we go again. No, that&#39;s not the problem. A similar i= ssue goes<br> =C2=A0 =C2=A0 about final.<br> <br> <br></div><div class=3D"im"> You can safely add virtual to a function where it wasn&#39;t previously<br> present without breaking code.<br> </div></blockquote> <br> If not breaking code is something of value to you, you should appreciate th= at final-by-default would break a bunch of code.</blockquote><div><br></div=
<div>Only once upon changing the default, and with the opportunity for a c=

this remains an ongoing issue forever.</div> </div></div></div> --089e0149ccae4d55f004ec99c96b--
Dec 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 3 December 2013 at 04:33:07 UTC, Manu wrote:
 On 3 December 2013 13:14, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org
 wrote:

 On 12/2/13 5:30 PM, Manu wrote:

 On 3 December 2013 08:43, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org 
 <mailto:SeeWebsiteForEmail erdani.org>>

 wrote:

     On 12/2/13 4:19 AM, Manu wrote:

         The problem is that virtual is irrevocable. It can't 
 be removed
         without
         breaking the API


     Here we go again. No, that's not the problem. A similar 
 issue goes
     about final.


 You can safely add virtual to a function where it wasn't 
 previously
 present without breaking code.

If not breaking code is something of value to you, you should appreciate that final-by-default would break a bunch of code.

Only once upon changing the default, and with the opportunity for a controlled deprecation path which clearly communicates with users. Otherwise this remains an ongoing issue forever.

Sorry but again we stray from the topic (Seems to happen in this forum almost always). The first step is to introduce a virtual keyword to avoid the "grouping" of your methods in final blocks. If the next step comes and change from virtual by default to final by default is another matter and should be discussed somewhere else after virtual was introduced.
Dec 03 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 3 December 2013 00:01, nazriel <spam dzfl.pl> wrote:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

I would support LDC project - so maybe more people would work on it. //*me* wishes he could use LDC with Vibe.d

Similarly I won't be around forever, and having a bus factor of 1 is taking some burdening as time drags on...
Dec 03 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b5d35b8e44a4404eca4299f
Content-Type: text/plain; charset=UTF-8

On 3 December 2013 17:43, Jacob Carlborg <doob me.com> wrote:

 On 2013-12-02 14:27, Michel Fortin wrote:

 I'm usually quite adverse about releasing unfinished features or
 products, which probably explains why *I* wouldn't merge. Although I
 obviously won't oppose it being merged if someone wants to. I'm just not
 sure it is worth the trouble for the core team right now given the lack
 of some key features.

I understand that. Although I think it's still usable as it is. It's so cumbersome and verbose to use Objective-C libraries from D that I think it's worth adding these features, even they're not complete.

C++ support in D is 'not complete', but what's there now is still very important and not considered a bad partial feature to have. I'd imagine that likewise, if the 'core' of Obj-C support is solid, then maybe it's worth it in the same sense? OSX and iOS are 2 of the most popular platforms on earth. The mobile space is probably the most important prospective target for D. I can't comment on the state it's in. But if what's there is solid and useful like the current C++ support, then it's an important start...? --047d7b5d35b8e44a4404eca4299f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3= December 2013 17:43, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailt= o:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> <div class=3D"im">On 2013-12-02 14:27, Michel Fortin wrote:<br></div><div c= lass=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;m usually quite adverse about releasing unfinished features or<br> products, which probably explains why *I* wouldn&#39;t merge. Although I<br=

t not<br> sure it is worth the trouble for the core team right now given the lack<br> of some key features.<br> </blockquote> <br></div> I understand that. Although I think it&#39;s still usable as it is. It&#39;= s so cumbersome and verbose to use Objective-C libraries from D that I thin= k it&#39;s worth adding these features, even they&#39;re not complete.</blo= ckquote> <div><br></div><div>C++ support in D is &#39;not complete&#39;, but what&#3= 9;s there now is still very important and not considered a bad partial feat= ure to have.</div><div>I&#39;d imagine that likewise, if the &#39;core&#39;= of Obj-C support is solid, then maybe it&#39;s worth it in the same sense?= </div> <div>OSX and iOS are 2 of the most popular platforms on earth. The mobile s= pace is probably the most important prospective target for D.</div><div>I c= an&#39;t comment on the state it&#39;s in. But if what&#39;s there is solid= and useful like the current C++ support, then it&#39;s an important start.= ..?</div> </div></div></div> --047d7b5d35b8e44a4404eca4299f--
Dec 03 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

Btw, speaking about paid stuff, if there is one thing I'd consider necessary to kickstart funds for is creation of formal language specification and keeping it maintained. It is one of things that don't go with volunteer efforts very well.
Dec 03 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
03-Dec-2013 21:00, Dicebot пишет:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

Btw, speaking about paid stuff, if there is one thing I'd consider necessary to kickstart funds for is creation of formal language specification and keeping it maintained. It is one of things that don't go with volunteer efforts very well.

+1 -- Dmitry Olshansky
Dec 03 2013
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 2 December 2013 at 13:51:39 UTC, Adam D. Ruppe wrote:

 The *whole point* of classes is to have virtual functions. If 
 you don't want them, don't write class methods! Use structs or 
 UFCS instead.

+1 I can only agree...
Dec 03 2013
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 2 December 2013 at 12:19:12 UTC, Manu wrote:
 On 2 December 2013 19:33, Dejan Lekic <dejan.lekic gmail.com> 
 wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

  Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

There's been endless discussions on the topic. There was a link to a thread with loads of discussion. The problem is that virtual is irrevocable. It can't be removed without breaking the API, which means it's not possible to optimise a library in that way at any time after it has already been released to the wild. The converse is not true. It has also been agreed that there is very little the compiler/optimiser can do to help. It's a dangerous default, it's got absolutely nothing to do with "I don't want to type final" as you helpfully simplified it. You can type 'virtual:' at the top, and you're set. Again, the converse doesn't stand, you can't practically type 'final:' at the top since there will inevitable by SOME virtual methods. We can spin off another thread if you like, or you can read through the old ones. I don't think it's going to go any further than the other threads already did.

No offense, so far I haven's seen a GOOD reason for making final to be the default. Your DIP51 is, to put mildly, pretty subjective. You care about performance, I get it, but I do not. Developers like me use classes exactly because methods are virtual. In my career I *rarely* had situation that I knew ahead my class method is *definitely* final. You say "dangerous". - I am quite sure people are aware of those "dangers". You say "people agreed". Who agreed? :) You say there have been endless discussions. Yes, I remember them but I do not remember anything conclusive after reading them. This is *a radical change*, and instead of "(unknown) people agreed" the community deserves a better explanation why are we switching to final as default storage class...
Dec 03 2013
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 3 December 2013 at 09:51:17 UTC, Iain Buclaw wrote:
 On 3 December 2013 00:01, nazriel <spam dzfl.pl> wrote:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

I would support LDC project - so maybe more people would work on it. //*me* wishes he could use LDC with Vibe.d

Similarly I won't be around forever, and having a bus factor of 1 is taking some burdening as time drags on...

+1
Dec 03 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic wrote:
 On Monday, 2 December 2013 at 12:19:12 UTC, Manu wrote:
 On 2 December 2013 19:33, Dejan Lekic <dejan.lekic gmail.com> 
 wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


and quite frankly I am not convinced at all. It is basically "I do not want to put final in front of my methods. Well, I do not want to put virtual in front of my methods... But this is perhaps something for another discussion...

There's been endless discussions on the topic. There was a link to a thread with loads of discussion. The problem is that virtual is irrevocable. It can't be removed without breaking the API, which means it's not possible to optimise a library in that way at any time after it has already been released to the wild. The converse is not true. It has also been agreed that there is very little the compiler/optimiser can do to help. It's a dangerous default, it's got absolutely nothing to do with "I don't want to type final" as you helpfully simplified it. You can type 'virtual:' at the top, and you're set. Again, the converse doesn't stand, you can't practically type 'final:' at the top since there will inevitable by SOME virtual methods. We can spin off another thread if you like, or you can read through the old ones. I don't think it's going to go any further than the other threads already did.

No offense, so far I haven's seen a GOOD reason for making final to be the default. Your DIP51 is, to put mildly, pretty subjective. You care about performance, I get it, but I do not.

bother the majority. ;) But back to the topic.
Dec 03 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Ok one more thing: Are you also against the introducing of the 
virtual keyword without introducing final by default?
Dec 03 2013
prev sibling next sibling parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 03.12.2013 19:10, Dejan Lekic wrote:

 No offense, so far I haven's seen a GOOD reason for making final to be
 the default.

The best reason I've got is that making something final is a breaking change, while making something virtual is not. That means: (with virtual by default) If you write a library and forget to make a function final, you're stuck with it. (with final by default) If you write a library and forget to make a function virtual, you just fix it.
 In my career I *rarely* had situation that I knew ahead my class method
 is *definitely* final.

Of course not. But see above.
 You say "dangerous". - I am quite sure people are aware of those "dangers".

I am absolutely certain some people are not aware of the dangers. -- Simen
Dec 03 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic wrote:
 This is *a radical change*, and instead of "(unknown) people 
 agreed" the community deserves a better explanation why are we 
 switching to final as default storage class...

Let me state in advance that I believe that in most situations people will leave the default option unless they have reason to (that is, stick with the virtual unless they have reason to mark something final, or stick with final unless they have reason to mark something virtual). For virtual, there is often less reason to realize something should be final as things look like they work until much later. Forgetting to stick a 'final' in front of your function will never give you a compiler error. That being said, some pros / cons of virtual/final by default. Obviously heavily biased. 1) The most obvious reason is final has better performance. Some effort can be taken to reduce the impact of virtual methods but ultimately there will always be a performance hit. In a large program, this may not be too substantial a hit. I consider this the weakest argument for final-by-default, but others who attempt to deliver as efficient as possible code consider it very important. 2) A function that is virtual cannot be changed to be final without breaking existing code. If you are writing a library and have a virtual method which you wish to change to final, anyone using that library that overrides your method will have their code break and require substantial design changes if they were relying on simply being able to override your method. If a method was final and is changed to be virtual later on, no code will break unless the developer then decides to change it back to final afterwards. 3) Related to the above, if a method is not virtual there is nothing you can do about it. A method might be perfectly capable of being virtual without issues, yet if the developer forgot to mark it as 'virtual' you cannot override it even though it may be safe to do so. 4) If we assume that the statement about people sticking with the default is true (which I strongly believe it is, yet lack actual data for), final by default means more 'virtual' keywords being stuck everywhere. For a language that may already be considered to have too many modifiers to stick in front of your methods, this would add yet another one for many class methods. 5) Marking something virtual is a huge commitment and makes substantial guarantees about implementation details. A simple example is a property. Making a property virtual is a statement that you will never access the field behind the property (assuming there is one), as someone may have overridden the property to use a different backing field or a constant value. This is something that requires actual acknowledgement, yet virtual by default does not require you to think about this as it's automatically virtual. This is actually a mistake I catch myself making not infrequently. A less obvious example is add vs addRange. If you implement a class to extend an existing collection yet add capabilities for storing length by overriding add/remove to increase/decrease length, should you override addRange and add range.length? What if something then overrides addRange for more efficient adding of multiple elements rather than calling add N times, or something that only sometimes calls add depending on the element type or state? These are considerations that require actual thought, and while simply adding a "virtual" keyword to them doesn't mean you thought about the implications, the very action of having to add this keyword makes it a conscious effort and so helps you consider the side-effects of adding it and what it means. I don't understand how virtual-by-default is even considered for new languages. It provides slight convenience while being error prone. Yet breaking almost every single D program is a huge issue and stability is something that D is desperately trying to achieve. I'd like virtual by default, but it's a hard sell now. I wouldn't mind updating my code for this and I feel it better to do this sort of change now rather than later when more/larger code uses D, but it is still a substantial code break. If it was actually done it would need a transition flag or such to help the process (final by default normally, virtual by default with the transition flag), and likely a virtual keyword implemented well ahead of time so people could start making their changes early and gradually.
Dec 03 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e013a14c47b09c904ecaff717
Content-Type: text/plain; charset=UTF-8

On 4 December 2013 12:58, Kapps <opantm2+spam gmail.com> wrote:

 On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic wrote:

 This is *a radical change*, and instead of "(unknown) people agreed" the
 community deserves a better explanation why are we switching to final as
 default storage class...

Let me state in advance that I believe that in most situations people will leave the default option unless they have reason to (that is, stick with the virtual unless they have reason to mark something final, or stick with final unless they have reason to mark something virtual). For virtual, there is often less reason to realize something should be final as things look like they work until much later. Forgetting to stick a 'final' in front of your function will never give you a compiler error. That being said, some pros / cons of virtual/final by default. Obviously heavily biased. 1) The most obvious reason is final has better performance. Some effort can be taken to reduce the impact of virtual methods but ultimately there will always be a performance hit. In a large program, this may not be too substantial a hit. I consider this the weakest argument for final-by-default, but others who attempt to deliver as efficient as possible code consider it very important.

I think this has a tendency to be underestimated until it is a project requirement. Consider that there may be any number of useful libraries available - many of which didn't explicitly try to deliver the most efficient possible code, by they are still useful libraries nonetheless - but pervasive use of virtual may unintentionally inhibit their usage in performance critical software. This is not conjecture, I've run in to this professionally on many occasions. And worse than C++, D has 1st class properties, which makes it much more important a consideration than in C++. What I'm proposing is simply that, with this change, it will not be a hidden/unintentional cost, but the placement of the keyword one way or another will result in library authors considering, even for just a moment, the reality of the _choice_ they are making. It can't be default, or the choice will be overlooked and the damage is done, since it can't be revoked. Library authors are very apprehensive to make breaking changes to their API and go bumping the major version of their software to fix an otherwise trivial performance issue. 2) A function that is virtual cannot be changed to be final without
 breaking existing code. If you are writing a library and have a virtual
 method which you wish to change to final, anyone using that library that
 overrides your method will have their code break and require substantial
 design changes if they were relying on simply being able to override your
 method. If a method was final and is changed to be virtual later on, no
 code will break unless the developer then decides to change it back to
 final afterwards.

 3) Related to the above, if a method is not virtual there is nothing you
 can do about it. A method might be perfectly capable of being virtual
 without issues, yet if the developer forgot to mark it as 'virtual' you
 cannot override it even though it may be safe to do so.

You can change it easily (open source), or request the change (which usually wouldn't be objected, since it's not a breaking change). And if neither of those are to your taste, you can very easily wrap it as a last resort; in D, 'alias this' makes wrapping things easier than ever. Those aren't options when going the other direction, rather, there is no option... you're simply screwed. And I have been on the receiving end of this on many occasions in C++, and it sucks! It will be much worse for D, since properties are more pervasive. 4) If we assume that the statement about people sticking with the default
 is true (which I strongly believe it is, yet lack actual data for), final
 by default means more 'virtual' keywords being stuck everywhere. For a
 language that may already be considered to have too many modifiers to stick
 in front of your methods, this would add yet another one for many class
 methods.

I have hard experience that shows that even when people know it's a critical performance penalty and a project requirement, they STILL stick with the default, either from habit, or ignorance/inexperience, or they simply forget. WRT adding additional modifiers, I'd make the argument that looking from the other (current) perspective where virtual is default and you need to explicitly mark functions final everywhere, you will end up with far more 'final' spam than you would with 'virtual' as you suggest. If that's not the case, then it's likely the truth is that D libraries are over-virtualised, and will suffer performance penalties as a result. The majority of functions in most OOP classes are properties and trivial accessors which should almost never be virtual. Imagine, making virtual function calls to access trivial properties? They can't be inlined anymore; inlining trivial accessors is one of the most important optimisations for OOP that there is. If people stick with the default, then D suffers severe performance penalties against C++ and even Java/C#/etc, since nothing can be done to optimise the calls. And like you say, you (and I) agree that most people will stick with the default in most cases unless they have good reason not to (ie, a compile error). 5) Marking something virtual is a huge commitment and makes substantial
 guarantees about implementation details. A simple example is a property.
 Making a property virtual is a statement that you will never access the
 field behind the property (assuming there is one), as someone may have
 overridden the property to use a different backing field or a constant
 value. This is something that requires actual acknowledgement, yet virtual
 by default does not require you to think about this as it's automatically
 virtual. This is actually a mistake I catch myself making not infrequently.

Yes, another very important point that I have tried to make many times. I support that it is important to acknowledge this commitment you have made. It can't reasonably be a default commitment, since it has severe performance and maintainability implications. A less obvious example is add vs addRange. If you implement a class to
 extend an existing collection yet add capabilities for storing length by
 overriding add/remove to increase/decrease length, should you override
 addRange and add range.length? What if something then overrides addRange
 for more efficient adding of multiple elements rather than calling add N
 times, or something that only sometimes calls add depending on the element
 type or state? These are considerations that require actual thought, and
 while simply adding a "virtual" keyword to them doesn't mean you thought
 about the implications, the very action of having to add this keyword makes
 it a conscious effort and so helps you consider the side-effects of adding
 it and what it means.

+1 hundred :) I don't understand how virtual-by-default is even considered for new
 languages. It provides slight convenience while being error prone. Yet
 breaking almost every single D program is a huge issue and stability is
 something that D is desperately trying to achieve. I'd like virtual by
 default, but it's a hard sell now. I wouldn't mind updating my code for
 this and I feel it better to do this sort of change now rather than later
 when more/larger code uses D, but it is still a substantial code break. If
 it was actually done it would need a transition flag or such to help the
 process (final by default normally, virtual by default with the transition
 flag), and likely a virtual keyword implemented well ahead of time so
 people could start making their changes early and gradually.

You mean you'd like virtual-by-default as you say (as is now), or you'd like final-by-default at the cost of the transition? There is a proposed transition process across a few releases which should make the transition relatively painless, at least, it wouldn't be error prone, since warnings/deprecation messages would assist the process. 1. 'virtual' keyword is introduced, 'override'-ing unattributed methods is a warning. 2. it becomes deprecated, but you can still compile with -d. 3. it becomes an error, but surely you've already taken the opportunity to update your software, right? --089e013a14c47b09c904ecaff717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4= December 2013 12:58, Kapps <span dir=3D"ltr">&lt;<a href=3D"mailto:opantm2= +spam gmail.com" target=3D"_blank">opantm2+spam gmail.com</a>&gt;</span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic = wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This is *a radical change*, and instead of &quot;(unknown) people agreed&qu= ot; the community deserves a better explanation why are we switching to fin= al as default storage class...<br> </blockquote> <br></div> Let me state in advance that I believe that in most situations people will = leave the default option unless they have reason to (that is, stick with th= e virtual unless they have reason to mark something final, or stick with fi= nal unless they have reason to mark something virtual). For virtual, there = is often less reason to realize something should be final as things look li= ke they work until much later. Forgetting to stick a &#39;final&#39; in fro= nt of your function will never give you a compiler error. That being said, = some pros / cons of virtual/final by default. Obviously heavily biased.<br> <br> 1) The most obvious reason is final has better performance. Some effort can= be taken to reduce the impact of virtual methods but ultimately there will= always be a performance hit. In a large program, this may not be too subst= antial a hit. I consider this the weakest argument for final-by-default, bu= t others who attempt to deliver as efficient as possible code consider it v= ery important.<br> </blockquote><div><br></div><div>I think this has a tendency to be underest= imated until it is a project requirement. Consider that there may be any nu= mber of useful libraries available - many of which didn&#39;t explicitly tr= y to deliver the most efficient possible code, by they are still useful lib= raries nonetheless - but pervasive use of virtual may unintentionally inhib= it their usage in performance critical software.</div> <div><br></div><div>This is not conjecture, I&#39;ve run in to this profess= ionally on many occasions. And worse than C++, D has 1st class properties, = which makes it much more important a consideration than in C++.</div><div> What I&#39;m proposing is simply that, with this change, it will not be a h= idden/unintentional cost, but the placement of the keyword one way or anoth= er will result in library authors considering, even for just a moment, the = reality of the _choice_ they are making. It can&#39;t be default, or the ch= oice will be overlooked and the damage is done, since it can&#39;t be revok= ed.</div> <div><br></div><div>Library authors are very apprehensive to make breaking = changes to their API and go bumping the major version of their software to = fix an otherwise trivial performance issue.</div><div><br></div><div><br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> 2) A function that is virtual cannot be changed to be final without breakin= g existing code. If you are writing a library and have a virtual method whi= ch you wish to change to final, anyone using that library that overrides yo= ur method will have their code break and require substantial design changes= if they were relying on simply being able to override your method. If a me= thod was final and is changed to be virtual later on, no code will break un= less the developer then decides to change it back to final afterwards.<br> <br> 3) Related to the above, if a method is not virtual there is nothing you ca= n do about it. A method might be perfectly capable of being virtual without= issues, yet if the developer forgot to mark it as &#39;virtual&#39; you ca= nnot override it even though it may be safe to do so.<br> </blockquote><div><br></div><div>You can change it easily (open source), or= request the change (which usually wouldn&#39;t be objected, since it&#39;s= not a breaking change). And if neither of those are to your taste, you can= very easily wrap it as a last resort; in D, &#39;alias this&#39; makes wra= pping things easier than ever. Those aren&#39;t options when going the othe= r direction, rather, there is no option... you&#39;re simply screwed. And I= have been on the receiving end of this on many occasions in C++, and it su= cks!</div> <div>It will be much worse for D, since properties are more pervasive.</div=
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=

4) If we assume that the statement about people sticking with the default i= s true (which I strongly believe it is, yet lack actual data for), final by= default means more &#39;virtual&#39; keywords being stuck everywhere. For = a language that may already be considered to have too many modifiers to sti= ck in front of your methods, this would add yet another one for many class = methods.<br> </blockquote><div><br></div><div>I have hard experience that shows that eve= n when people know it&#39;s a critical performance penalty and a project re= quirement, they STILL stick with the default, either from habit, or ignoran= ce/inexperience, or they simply forget.</div> <div><br></div><div>WRT adding additional modifiers, I&#39;d make the argum= ent that looking from the other (current) perspective where virtual is defa= ult and you need to explicitly mark functions final everywhere, you will en= d up with far more &#39;final&#39; spam than you would with &#39;virtual&#3= 9; as you suggest.</div> <div>If that&#39;s not the case, then it&#39;s likely the truth is that D l= ibraries are over-virtualised, and will suffer performance penalties as a r= esult.<br></div><div><br></div><div>The majority of functions in most OOP c= lasses are properties and trivial accessors which should almost never be vi= rtual. Imagine, making virtual function calls to access trivial properties?= They can&#39;t be inlined anymore; inlining trivial accessors is one of th= e most important optimisations for OOP that there is.</div> <div>If people stick with the default, then D suffers severe performance pe= nalties against C++ and even Java/C#/etc, since nothing can be done to opti= mise the calls. And like you say, you (and I) agree that most people will s= tick with the default in most cases unless they have good reason not to (ie= , a compile error).</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 5) Marking something virtual is a huge commitment and makes substantial gua= rantees about implementation details. A simple example is a property. Makin= g a property virtual is a statement that you will never access the field be= hind the property (assuming there is one), as someone may have overridden t= he property to use a different backing field or a constant value. This is s= omething that requires actual acknowledgement, yet virtual by default does = not require you to think about this as it&#39;s automatically virtual. This= is actually a mistake I catch myself making not infrequently.<br> </blockquote><div><br></div><div>Yes, another very important point that I h= ave tried to make many times. I support that it is important to acknowledge= this commitment you have made. It can&#39;t reasonably be a default commit= ment, since it has severe performance and maintainability implications.</di= v> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> A less obvious example is add vs addRange. If you implement a class to exte= nd an existing collection yet add capabilities for storing length by overri= ding add/remove to increase/decrease length, should you override addRange a= nd add range.length? What if something then overrides addRange for more eff= icient adding of multiple elements rather than calling add N times, or some= thing that only sometimes calls add depending on the element type or state?= These are considerations that require actual thought, and while simply add= ing a &quot;virtual&quot; keyword to them doesn&#39;t mean you thought abou= t the implications, the very action of having to add this keyword makes it = a conscious effort and so helps you consider the side-effects of adding it = and what it means.<br> </blockquote><div><br></div><div>+1 hundred :)</div><div><br></div><div><br=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=

I don&#39;t understand how virtual-by-default is even considered for new la= nguages. It provides slight convenience while being error prone. Yet breaki= ng almost every single D program is a huge issue and stability is something= that D is desperately trying to achieve. I&#39;d like virtual by default, = but it&#39;s a hard sell now. I wouldn&#39;t mind updating my code for this= and I feel it better to do this sort of change now rather than later when = more/larger code uses D, but it is still a substantial code break. If it wa= s actually done it would need a transition flag or such to help the process= (final by default normally, virtual by default with the transition flag), = and likely a virtual keyword implemented well ahead of time so people could= start making their changes early and gradually.<br> </blockquote><div><br></div><div>You mean you&#39;d like virtual-by-default= as you say (as is now), or you&#39;d like final-by-default at the cost of = the transition?</div><div><br></div><div>There is a proposed transition pro= cess across a few releases which should make the transition relatively pain= less, at least, it wouldn&#39;t be error prone, since warnings/deprecation = messages would assist the process.</div> <div>1. &#39;virtual&#39; keyword is introduced, &#39;override&#39;-ing una= ttributed methods is a warning.</div><div>2. it becomes deprecated, but you= can still compile with -d.</div><div>3. it becomes an error, but surely yo= u&#39;ve already taken the opportunity to update your software, right?</div=

--089e013a14c47b09c904ecaff717--
Dec 03 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:
 You mean you'd like virtual-by-default as you say (as is now), 
 or you'd
 like final-by-default at the cost of the transition?

Sorry, I meant to say I'd like final by default, but I can understand people being hesitant with the breakage required.
 There is a proposed transition process across a few releases 
 which should
 make the transition relatively painless, at least, it wouldn't 
 be error
 prone, since warnings/deprecation messages would assist the 
 process.
 1. 'virtual' keyword is introduced, 'override'-ing unattributed 
 methods is
 a warning.
 2. it becomes deprecated, but you can still compile with -d.
 3. it becomes an error, but surely you've already taken the 
 opportunity to
 update your software, right?

This transition also works well. It does mean that the performance benefits would not occur until step 3, but while giving time to transition it also immediately provides the safety benefits. Ideally it would even catch bugs in peoples code as they make the required changes to add virtual where needed. The only issue is that it pretty much guarantees that most libraries that make use of classes and are no longer maintained will fail to compile, but honestly, I don't know think many projects will compile anyways when using a compiler / Phobos version that's more than a year newer than when the library was last modified.
Dec 03 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c30facfca79e04ecb0d08e
Content-Type: text/plain; charset=UTF-8

On 4 December 2013 17:24, Kapps <opantm2+spam gmail.com> wrote:

 On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:

 There is a proposed transition process across a few releases which should

 prone, since warnings/deprecation messages would assist the process.
 1. 'virtual' keyword is introduced, 'override'-ing unattributed methods is
 a warning.
 2. it becomes deprecated, but you can still compile with -d.
 3. it becomes an error, but surely you've already taken the opportunity to
 update your software, right?

This transition also works well. It does mean that the performance benefits would not occur until step 3, but while giving time to transition it also immediately provides the safety benefits. Ideally it would even catch bugs in peoples code as they make the required changes to add virtual where needed. The only issue is that it pretty much guarantees that most libraries that make use of classes and are no longer maintained will fail to compile, but honestly, I don't know think many projects will compile anyways when using a compiler / Phobos version that's more than a year newer than when the library was last modified.

Indeed. I think it's very safe to say that any un-maintained code already won't compile. This isn't the first, or even the greatest in magnitude breaking change that there's been recently. --001a11c30facfca79e04ecb0d08e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4= December 2013 17:24, Kapps <span dir=3D"ltr">&lt;<a href=3D"mailto:opantm2= +spam gmail.com" target=3D"_blank">opantm2+spam gmail.com</a>&gt;</span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote= :<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">There is a proposed transition process acros= s a few releases which should<br></blockquote></div><div class=3D"im"><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> make the transition relatively painless, at least, it wouldn&#39;t be error= <br> prone, since warnings/deprecation messages would assist the process.<br> 1. &#39;virtual&#39; keyword is introduced, &#39;override&#39;-ing unattrib= uted methods is<br> a warning.<br> 2. it becomes deprecated, but you can still compile with -d.<br> 3. it becomes an error, but surely you&#39;ve already taken the opportunity= to<br> update your software, right?<br> </blockquote> <br></div> This transition also works well. It does mean that the performance benefits= would not occur until step 3, but while giving time to transition it also = immediately provides the safety benefits. Ideally it would even catch bugs = in peoples code as they make the required changes to add virtual where need= ed. The only issue is that it pretty much guarantees that most libraries th= at make use of classes and are no longer maintained will fail to compile, b= ut honestly, I don&#39;t know think many projects will compile anyways when= using a compiler / Phobos version that&#39;s more than a year newer than w= hen the library was last modified.<br> </blockquote><div><br></div><div>Indeed. I think it&#39;s very safe to say = that any un-maintained code already won&#39;t compile. This isn&#39;t the f= irst, or even the greatest in magnitude breaking change that there&#39;s be= en recently.<br> </div></div></div></div> --001a11c30facfca79e04ecb0d08e--
Dec 04 2013
prev sibling next sibling parent "nazriel" <spam dzfl.pl> writes:
On Tuesday, 3 December 2013 at 09:51:17 UTC, Iain Buclaw wrote:
 On 3 December 2013 00:01, nazriel <spam dzfl.pl> wrote:
 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:
 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?

I would support LDC project - so maybe more people would work on it. //*me* wishes he could use LDC with Vibe.d

Similarly I won't be around forever, and having a bus factor of 1 is taking some burdening as time drags on...

Exactly my point. Other 2 compilers seem to be unnoticed as the ones who need help. I believe that for some people ldc&gdc are the only reason to even consider D as an alternative to C or C++, given how much slower are binaries generated by DMD. I am very worried seeing commits in gdc/ldc being made by 1 man for the past weeks. Just my 2 cents :)
Dec 04 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 4 December 2013 08:28, Jacob Carlborg <doob me.com> wrote:
 On 2013-12-03 17:55, Manu wrote:

 C++ support in D is 'not complete', but what's there now is still very
 important and not considered a bad partial feature to have.
 I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
 maybe it's worth it in the same sense?
 OSX and iOS are 2 of the most popular platforms on earth. The mobile
 space is probably the most important prospective target for D.
 I can't comment on the state it's in. But if what's there is solid and
 useful like the current C++ support, then it's an important start...?

I agree but Michel has a point as well. Walter, I think it was, has also said that D will never have complete support for C++ because that will require to build in a C++ compiler in the D compiler. That's not something we would like to do.

What complete support? All you really need is: 1) ABI compatibility when passing around basic types.... check [1] 2) ABI compatibility when passing around structs.... check [1] 3) C++ mangling when declaring functions/decls as extern(C++).... check 4) ABI compatibility with C++ classes.... check [1] Oh wait... dmd has a problem... https://d.puremagic.com/issues/show_bug.cgi?id=5570 Forget templates and everything else...
Dec 04 2013
prev sibling next sibling parent "Nick" <nmsmith65 gmail.com> writes:
On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:
 The majority of functions in most OOP classes are properties 
 and trivial
 accessors which should almost never be virtual. Imagine, making 
 virtual
 function calls to access trivial properties? They can't be 
 inlined anymore;
 inlining trivial accessors is one of the most important 
 optimisations for
 OOP that there is.

This is an absolutely important point that should be considered the foundation for the argument for final-by-default. Your average programmer is NOT going to tag everything as final, and the cost of virtual accessors could be tremendous. There's no argument for virtual-by-default that is nearly as powerful as this.
Dec 04 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e0112cb9ecfe23904ecb2113e
Content-Type: text/plain; charset=UTF-8

On 4 December 2013 19:24, Jacob Carlborg <doob me.com> wrote:

 On 2013-12-04 10:12, Iain Buclaw wrote:

  Forget templates and everything else...

Then it's not complete, just as I said.

In a sense. But I don't think the goal is to be able to write C++ code in D. It's just to achieve binary compatibility. Templates in C++ must be declared in header files, and are rarely present in libs. You almost never link a template instance. In the extremely rare event that you want to (I've never wanted to), it's not inconceivable that an extern(C++) template with super-restrictive template parameter rules could be made to mangle the same as C++, and then it truly would be complete :) I personally have no use for this though... but it's probably technically possible. --089e0112cb9ecfe23904ecb2113e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 4= December 2013 19:24, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailt= o:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> <div class=3D"im">On 2013-12-04 10:12, Iain Buclaw wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Forget templates and everything else...<br> </blockquote> <br></div> Then it&#39;s not complete, just as I said.</blockquote><div><br></div><div=
In a sense. But I don&#39;t think the goal is to be able to write C++ code=

n C++ must be declared in header files, and are rarely present in libs. You= almost never link a template instance.</div> <div>In the extremely rare event that you want to (I&#39;ve never wanted to= ), it&#39;s not inconceivable that an extern(C++) template with super-restr= ictive template parameter rules could be made to mangle the same as C++, an= d then it truly would be complete :)</div> <div>I personally have no use for this though... but it&#39;s probably tech= nically possible.</div></div></div></div> --089e0112cb9ecfe23904ecb2113e--
Dec 04 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.
Dec 04 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/4/13 6:12 AM, Daniel Davidson wrote:
 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling
 wrote:
 On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.

If you're willing you pay you may want to contact them. Andrei
Dec 04 2013
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.01.2014 04:19, schrieb Brad Anderson:
 On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson
 wrote:
 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling
 wrote:
 On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.

Sönke has already started work on this: https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d I'm not sure what remains for it to be integrated.

Once I discussed with the responsible guy over at HN. I would say he is pretty open to have D as well, he just had some issues getting it up. -- Paulo
Jan 11 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 4 December 2013 at 09:31:06 UTC, Manu wrote:
 On 4 December 2013 19:24, Jacob Carlborg <doob me.com> wrote:

 On 2013-12-04 10:12, Iain Buclaw wrote:

  Forget templates and everything else...

Then it's not complete, just as I said.

In a sense. But I don't think the goal is to be able to write C++ code in D. It's just to achieve binary compatibility. Templates in C++ must be declared in header files, and are rarely present in libs. You almost never link a template instance. In the extremely rare event that you want to (I've never wanted to), it's not inconceivable that an extern(C++) template with super-restrictive template parameter rules could be made to mangle the same as C++, and then it truly would be complete :) I personally have no use for this though... but it's probably technically possible.

In Windows you have COM and now WinRT as a C++ ABI of some sort, what about all the other platforms? -- Paulo
Dec 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:
 ...

Can you address proposal to move all such functions into UFCS instead? What are possible issues in your opinion as compared to declaring them as final inside class?
Dec 04 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/12/13 14:22, Dicebot wrote:
 Can you address proposal to move all such functions into UFCS instead? What are
 possible issues in your opinion as compared to declaring them as final inside
 class?

This was discussed at length previously, so it may be an idea to search the archives for the original debate. The killer argument really came down to two points -- of which I'd say the second was the one that really swung it: * Performance -- with virtual-by-default, we also have slower performance by default. Users who casually try out D will probably be put off by this and not bother to explore far enough to realize they have to use "final" to get better performance. * Breaking changes -- with final by default, if you accidentally forget to mark a method as virtual, you can correct this without affecting downstream users. By contrast with virtual by default, if you incorrectly forget to mark a method as final, you can't correct it later without potentially breaking downstream code. The latter argument is explained in some detail in an interview with one of the main C# designers, discussing why they went for final-by-default in their class design.
Dec 04 2013
prev sibling next sibling parent "Fra" <Fra b.it> writes:
Wow, this topic went far more ahead of what I originally 
expected. Nice!

A nice idea that came out is that we should create some form of 
kickstarter for bigger projects (AA, GDC & LGD, formal 
specification of the language, may I add in ddmd?). Anyone here 
willing to take this responsibility?

I would step in but I'm a D newbie, I would have no idea about 
the work required to fix stuff or to get better support for the 
gcc and llvm backends. I'm just an entusiast but I've been 
playing with D and following the language for 2 years, give or 
take. I have now a chance to try it in for a bigger project so 
I'm "more concerned" about development and support of the 
language.
Dec 04 2013
prev sibling next sibling parent "Daniel Davidson" <nospam spam.com> writes:
On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
Wakeling wrote:
 On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.
Dec 04 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 4 December 2013 at 08:01:25 UTC, Manu wrote:
 Indeed. I think it's very safe to say that any un-maintained 
 code already won't compile. This isn't the first, or even the 
 greatest in magnitude breaking change that there's been 
 recently.

Actually, a lot of my old code still compiles, and part of the reason is a lot of it is written in a more Java style than using the fancier, more likely to change features.... Though, to tell you the truth, I'm not sure just how many methods I've overridden in child classes. There's definitely some but probably not a huge number (at least excluding interfaces).
Dec 04 2013
prev sibling next sibling parent "Daniel Davidson" <nospam spam.com> writes:
On Wednesday, 4 December 2013 at 16:21:25 UTC, Andrei 
Alexandrescu wrote:
 On 12/4/13 6:12 AM, Daniel Davidson wrote:
 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
 Wakeling
 wrote:
 On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.

If you're willing you pay you may want to contact them. Andrei

No big money, just recent Facebook bounty style numbers. But this task is bigger than many of the bugs. I would not want to insult the contributors with low numbers. It is more for fun and I think done right the publicity is meaningful because the people going to that side are looking for edge. I would kick in something like $80 to have them get vibe on the site and an extra $100 if/when they beat Go in more than half the benchmarks :-)
Dec 04 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 01 Dec 2013 09:09:32 +0100
schrieb "sclytrack" <sclytrack fake.com>:

 
 Re: If you had money to place for a bounty, what would you choose?
 
 Official debian packages for gdc, derelict, gtkd, vibed.

What compiler and D version should those libraries be compiled with? The reason I ask this is that current D compilers produce incompatible ecosystems. You would need a gtkd-dmd, gtkd-gdc and gtkd-ldc package (or one big package with all three) and give what is supposedly one library three different file names to link against. -- Marco
Dec 04 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 December 2013 at 09:36:03 UTC, Dejan Lekic wrote:
 4) curl out of Phobos. Replaced by std.net.http package would 
 be an extra plus. And yes, I know that curl is more than just a 
 http client, all other supported protocols would go into 
 std.net eventually.

I don't remember if I already said this or not but I started slapping together some new http stuff last year https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/http2.d check out the main() function at the bottom to see how it works (so far). Not fancy D code, but I don't think fancy code is necessary here. All requests are done async and it automatically reuses connections when it can.
Jan 10 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson
wrote:
 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
 Wakeling wrote:
 On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.

Sönke has already started work on this: https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d I'm not sure what remains for it to be integrated.
Jan 10 2014
prev sibling next sibling parent "Daniel Davidson" <nospam spam.com> writes:
On Saturday, 11 January 2014 at 03:19:14 UTC, Brad Anderson wrote:
 On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson
 wrote:
 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
 Wakeling wrote:
 On 28/11/13 22:01, Fra wrote:
 What would your choice be?

A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D.

+1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity.

Sönke has already started work on this: https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d I'm not sure what remains for it to be integrated.

Just saw this. Great. Hopefully some encouraging numbers coming soon!
Jan 26 2014
prev sibling parent "sclytrack" <sclytrack fake.com> writes:
On Thursday, 5 December 2013 at 05:09:03 UTC, Marco Leise wrote:
 Am Sun, 01 Dec 2013 09:09:32 +0100
 schrieb "sclytrack" <sclytrack fake.com>:

 
 Re: If you had money to place for a bounty, what would you 
 choose?
 
 Official debian packages for gdc, derelict, gtkd, vibed.

What compiler and D version should those libraries be compiled with? The reason I ask this is that current D compilers produce incompatible ecosystems. You would need a gtkd-dmd, gtkd-gdc and gtkd-ldc package (or one big package with all three) and give what is supposedly one library three different file names to link against.

gdc version. ldc seems to be stuck in unstable.
Jun 10 2014