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 reply "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
parent reply 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.
 


Jonathan,

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
parent reply "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.


 Jonathan,

 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
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.


 Jonathan,

 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


 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.


I was thinking of us as Greece and them as Eurozone - what effects on DMD?
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 reply 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
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 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 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