www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - typedef alive and well?

reply Steve Teale <steve.teale britseyeview.com> writes:
I see that Walter just fixed a typedef bug in 2.056, even though I was 
just ticked of for even thinking of using one ;=)

Steve
Nov 03 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 03-11-2011 17:22, Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I was
 just ticked of for even thinking of using one ;=)

 Steve

Shouldn't that be long deprecated in favor of alias...? - Alex
Nov 03 2011
parent Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 03 Nov 2011 17:28:53 +0100, Alex Rønne Petersen wrote:

 On 03-11-2011 17:22, Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I was
 just ticked of for even thinking of using one ;=)

Shouldn't that be long deprecated in favor of alias...?

That's what everybody told me. Since it is not perfect it must die. Steve
Nov 03 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 03, 2011 09:22 Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I was
 just ticked of for even thinking of using one ;=)

He probably fixed it because it hasn't actually been given the axe yet, but it's definitely going to get the axe - and probably soon, since there was some discussion of wanting to remove (or at least deprecate) features that are definitely going to be removed before gdc actually makes it into gcc so that the changes are less disruptive when they happen. - Jonathan M Davis
Nov 03 2011
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 03 Nov 2011 13:22:49 -0400, Jonathan M Davis wrote:

 On Thursday, November 03, 2011 09:22 Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I was
 just ticked of for even thinking of using one ;=)

He probably fixed it because it hasn't actually been given the axe yet, but it's definitely going to get the axe - and probably soon, since there was some discussion of wanting to remove (or at least deprecate) features that are definitely going to be removed before gdc actually makes it into gcc so that the changes are less disruptive when they happen.

I thank you for your reply. I was just watching Sarkozy at the G20 talking about the potential Greek referendum. He took a similarly firm view. The outcome of that situation remains TBD. I wonder if D in gcc might be rather like the Eurozone. Steve
Nov 03 2011
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 03 Nov 2011 18:22:49 +0100, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, November 03, 2011 09:22 Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I was
 just ticked of for even thinking of using one ;=)

He probably fixed it because it hasn't actually been given the axe yet, but it's definitely going to get the axe - and probably soon, since there was some discussion of wanting to remove (or at least deprecate) features that are definitely going to be removed before gdc actually makes it into gcc so that the changes are less disruptive when they happen. - Jonathan M Davis

I think we need to change the release policy to make that happen. Honestly the half-life period for D code using the mainline dmd is about a few weeks and is released on ~monthly base. This is a heavy restriction to attract professional development. Currently this is creates the unlucky situation of deferring useful changes to some projected D3, while still breaking the D language all too often. I think there's a lot to learn from http://python.org/download/releases/. For example somebody changing from Python2.5 to 2.7 is anticipating some breaking changes, not so much for a change from dmd2.053 to dmd2.056. martin
Nov 03 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Martin Nowak:

 I think there's a lot to learn from http://python.org/download/releases/.
 For example somebody changing from Python2.5 to 2.7 is anticipating
 some breaking changes, not so much for a change from dmd2.053 to dmd2.056.

There is a difference between Python 2.5 and the current D2. D/DMD contains several unfinished features (see recent large changes in inout or CTFE), and several design holes that are quite open still (array covariance, purity details to be fixed still, some parts of the const system, etc). So while Python2.5 is a mature language that is essentially only gaining new features (slowly, there was even a moratorium for the enhancements, to allow pypy and jython to catch up, that was recently lifted), D2 despite its age is not mature yet, and it probably needs some changes still, maybe some small breaking too. (I am keeping a list less than a dozen of tiny breaking changes for D, most of them were not discussed much yet). Bye, bearophile
Nov 03 2011
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Thu, 3 Nov 2011, Martin Nowak wrote:

 I think we need to change the release policy to make that happen.
 Honestly the half-life period for D code using the mainline dmd
 is about a few weeks and is released on ~monthly base.
 This is a heavy restriction to attract professional development.
 
 Currently this is creates the unlucky situation of deferring useful changes
 to some projected D3, while still breaking the D language all too often.
 
 I think there's a lot to learn from http://python.org/download/releases/.
 For example somebody changing from Python2.5 to 2.7 is anticipating
 some breaking changes, not so much for a change from dmd2.053 to dmd2.056.
 
 martin

While I don't disagree with the larger point, I do feel compelled to clarify that it's not dmd or the language that's making most of the backwards incompatible changes, it's phobos. Walter has been considerably more conservative in what breaking changes are acceptable.
Nov 03 2011
parent David Nadlinger <see klickverbot.at> writes:
On 11/3/11 7:44 PM, Brad Roberts wrote:
 While I don't disagree with the larger point, I do feel compelled to
 clarify that it's not dmd or the language that's making most of the
 backwards incompatible changes, it's phobos.

I don't think this is generally true – for template metaprogramming-heavy code, DMD changes (regressions/bugfixes subtly altering behavior of some of the less-defined areas of the language) usually cause me much more of a headache than Phobos does. David
Nov 03 2011
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 03 Nov 2011 19:44:36 +0100, Brad Roberts <braddr puremagic.com>  
wrote:

 On Thu, 3 Nov 2011, Martin Nowak wrote:

 I think we need to change the release policy to make that happen.
 Honestly the half-life period for D code using the mainline dmd
 is about a few weeks and is released on ~monthly base.
 This is a heavy restriction to attract professional development.

 Currently this is creates the unlucky situation of deferring useful  
 changes
 to some projected D3, while still breaking the D language all too often.

 I think there's a lot to learn from  
 http://python.org/download/releases/.
 For example somebody changing from Python2.5 to 2.7 is anticipating
 some breaking changes, not so much for a change from dmd2.053 to  
 dmd2.056.

 martin

While I don't disagree with the larger point, I do feel compelled to clarify that it's not dmd or the language that's making most of the backwards incompatible changes, it's phobos. Walter has been considerably more conservative in what breaking changes are acceptable.

True, but that has it's own drawbacks. Also adding bugs for new features can be considered as a breaking change. There's a lot to gain from splitting maintenance and feature development. martin
Nov 03 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 03.11.2011, 18:43 Uhr, schrieb Steve Teale  
<steve.teale britseyeview.com>:

 On Thu, 03 Nov 2011 13:22:49 -0400, Jonathan M Davis wrote:

 On Thursday, November 03, 2011 09:22 Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I was
 just ticked of for even thinking of using one ;=)

He probably fixed it because it hasn't actually been given the axe yet, but it's definitely going to get the axe - and probably soon, since there was some discussion of wanting to remove (or at least deprecate) features that are definitely going to be removed before gdc actually makes it into gcc so that the changes are less disruptive when they happen.

I thank you for your reply. I was just watching Sarkozy at the G20 talking about the potential Greek referendum. He took a similarly firm view. The outcome of that situation remains TBD. I wonder if D in gcc might be rather like the Eurozone. Steve

It caused some discussion. Someone didn't like the naked-function feature or other traits of D that (official) support has to be written for in the GCC backend first. But I don't see how D would become unbearable for the GCC people as long as the frontend is maintained. There have been other language frontends bitrotting before, so the 'Eurozone' is suspicious and looks closely on who is joining them. Since D in GCC is often requested I believe it will have a positive future there and give the language more momentum, since people don't have to leave their known and pre-installed tool chain.
Nov 03 2011
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 03 Nov 2011 23:42:01 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:

 Martin Nowak:

 I think there's a lot to learn from  
 http://python.org/download/releases/.
 For example somebody changing from Python2.5 to 2.7 is anticipating
 some breaking changes, not so much for a change from dmd2.053 to  
 dmd2.056.

There is a difference between Python 2.5 and the current D2. D/DMD contains several unfinished features (see recent large changes in inout or CTFE), and several design holes that are quite open still (array covariance, purity details to be fixed still, some parts of the const system, etc). So while Python2.5 is a mature language that is essentially only gaining new features (slowly, there was even a moratorium for the enhancements, to allow pypy and jython to catch up, that was recently lifted), D2 despite its age is not mature yet, and it probably needs some changes still, maybe some small breaking too. (I am keeping a list less than a dozen of tiny breaking changes for D, most of them were not discussed much yet). Bye, bearophile

That's exactly the point, there are quite a lot of unfinished features that affect code. This does not only cause regressions but lets one run into frustrating deadends (a domain C++ sets the gold standard for). Just to name a few walls I hit regularly. - const, inout functions - lots of math in CTFE but no exp/log family functions - quite some tuple improvements but also many unexpected black holes The systematic misconception is to handle these features as bugfixes. They are even (partly) tracked in bug reporting tool. Developing feature specs deserves to be a separate process. Experimental or unfinished features should not get into the mainline branch. Depending on the size of a feature there should at least be a rough concept. Implementing features out of opportunity will ultimately turn everything into spaghetti. I would also like to see that the regular enhancement request bombardment were turned into something productive. The 1.5 day attention span on the mailing list are definitely not fruitful for language developing. And because this is all too negative, I propose the following process using the language specifications at github:d-programming-language.org. - The language specifications are made version specific (e.g. 2.6, partly handled by tags already). - Branches are created for the next 2(?) minor versions ahead of the current release cycle. Another one is created for the next major version. - We adopt a pull based development for the language specification similar to that for phobos (review queue, review manager, voting). - Specs are lined with acceptance tests. Ideally this would be the code examples. - The compiler strives to fulfill the specs. - Specs are added to the autotester. Not sure if github:d-programming-language.org can handle all this appropriately, but it seems worth a try.
Nov 03 2011
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 03 Nov 2011 20:47:48 +0100, Marco Leise wrote:

 Am 03.11.2011, 18:43 Uhr, schrieb Steve Teale
 <steve.teale britseyeview.com>:
 
 On Thu, 03 Nov 2011 13:22:49 -0400, Jonathan M Davis wrote:

 On Thursday, November 03, 2011 09:22 Steve Teale wrote:
 I see that Walter just fixed a typedef bug in 2.056, even though I
 was just ticked of for even thinking of using one ;=)

He probably fixed it because it hasn't actually been given the axe yet, but it's definitely going to get the axe - and probably soon, since there was some discussion of wanting to remove (or at least deprecate) features that are definitely going to be removed before gdc actually makes it into gcc so that the changes are less disruptive when they happen.

I thank you for your reply. I was just watching Sarkozy at the G20 talking about the potential Greek referendum. He took a similarly firm

feature or other traits of D that (official) support has to be written for in the GCC backend first. But I don't see how D would become unbearable for the GCC people as long as the frontend is maintained. There have been other language frontends bitrotting before, so the 'Eurozone' is suspicious and looks closely on who is joining them. Since D in GCC is often requested I believe it will have a positive future there and give the language more momentum, since people don't have to leave their known and pre-installed tool chain.

I was thinking of us as Greece and them as Eurozone - what effects on DMD?
Nov 03 2011