Difference between revisions of "Language design discussions"

From D Wiki
Jump to: navigation, search
(Properties)
 
(42 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
D is an evolving and complex language. New features are proposed, unexpected interaction in old ones get found, design issues are raised. All this may involve hard debates in D newsgroup and if often forgotten. This page serves as an index for major design discussions and proposals.
 
D is an evolving and complex language. New features are proposed, unexpected interaction in old ones get found, design issues are raised. All this may involve hard debates in D newsgroup and if often forgotten. This page serves as an index for major design discussions and proposals.
  
== Main DIP index ==
+
Formal improvement proposals can be found on the [[DIPs|main DIP index]].
[[DIPs]]
 
  
== Discussed design issues and free-form proposals ==
 
=== Properties ===
 
===== Description =====
 
  
===== Thread =====
+
== Properties ==
* [http://forum.dlang.org/thread/ceukykobasewoexsrveb@forum.dlang.org Initial discussion where this topic has rised]
+
==== Description ====
* [http://forum.dlang.org/thread/kdqrnl$13ft$1@digitalmars.com Walters follow-up with proposal to kill property, most info here]
+
Initial @property design has issues. How can it be changed or even discarded at all?
  
===== Essential moments =====
+
==== Thread ====
 +
* [http://forum.dlang.org/post/ceukykobasewoexsrveb@forum.dlang.org Initial discussion where this topic has rised]
 +
* [http://forum.dlang.org/post/kdqrnl$13ft$1@digitalmars.com Walters follow-up with proposal to kill property, most info here]
 +
 
 +
==== Essential moments ====
 
[[Property Discussion Wrap-up]]
 
[[Property Discussion Wrap-up]]
  
===== Proposals =====
+
==== Proposals ====
[[Property Discussion Proposal 1]]
+
* [[Property Discussion Proposal 1]]
 +
* [[DIP21]]
 +
 
 +
 
 +
 
 +
== Access specifiers and symbol visibility ==
 +
==== Description ====
 +
Currently there is feature like "static global" in C or "unnamed namespace" in C++. Access specifiers for module-level symbols control access, not visibility. Ability to hide symbols needs to be added without breaking current access system.
 +
 
 +
As a result of discussion, Walter has asked for DIP on this topic.
 +
 
 +
==== Essential moments ====
 +
* [http://forum.dlang.org/post/kb86il$1u9v$1@digitalmars.com Walter's final resolution about topics to cover in DIP]
 +
 
 +
==== Thread ====
 +
* [http://forum.dlang.org/post/iakfgxjlfzrbxerxpria@forum.dlang.org Initial thread that has raised this topic]
 +
* [http://forum.dlang.org/post/llizpsrachdtqtshppud@forum.dlang.org Follow-up about current state of affairs]
 +
* [[Access specifiers and visibility]] - combined data to make a decision upon
 +
 
 +
==== Proposal ====
 +
[[DIP22]]
 +
 
 +
 
 +
 
 +
== auto ref ==
 +
==== Description ====
 +
==== Essential moments ====
 +
 
 +
==== Thread ====
 +
* [http://forum.dlang.org/post/nirfuenixutsbgyrcsla@forum.dlang.org auto ref - again]
 +
 
 +
 
 +
== <code>volatile</code> ==
 +
 
 +
=== Threads ===
 +
* [http://forum.dlang.org/post/lq3kq8$pa3$1@digitalmars.com July 2014 Discussion]
 +
* [http://forum.dlang.org/post/mailman.1081.1400818840.2907.d.gnu@puremagic.com May~June 2014 Discussion]
 +
* [http://forum.dlang.org/post/bifrvifzrhgocrejepvc@forum.dlang.org October 2013 Discussion]
 +
* [http://forum.dlang.org/post/mailman.921.1378464218.1719.d.gnu@puremagic.com September 2013 Discussion]
 +
* [http://forum.dlang.org/post/CAEnAdhaoDoTge+Hs=od4aK_6CkvFQau75iokGK0BxMHw7fw9jA@mail.gmail.com July 2012 Discussion]
 +
* [http://forum.dlang.org/post/cdie80$1518$1@digitaldaemon.com July 2004 Discussion]
 +
* [http://forum.dlang.org/post/cbjgmm$27ia$1@digitaldaemon.com June 2004 Discussion]
 +
* [http://forum.dlang.org/post/pan.2004.05.09.01.08.26.766288@swieton.net May 2004 Discussion]
 +
* [http://forum.dlang.org/post/3C9A43BC.AFBA03BA@netfrastructure.com March 2002 Discussion]
 +
 
 +
=== Essential Moments ===
 +
* [http://forum.dlang.org/post/lq4k9h$1n6d$1@digitalmars.com Walter implements peek/poke intrinsics discouraging continued discussion on DIP62]
 +
* [http://forum.dlang.org/post/mailman.2445.1382596627.1719.digitalmars-d@puremagic.com <code>shared</code> considered a volatile type in GDC], [http://forum.dlang.org/post/l4ecan$6ss$1@digitalmars.com more] [http://forum.dlang.org/post/mailman.2480.1382655175.1719.digitalmars-d@puremagic.com more]
 +
* [http://forum.dlang.org/post/mailman.2454.1382619958.1719.digitalmars-d@puremagic.com compiler does not cache shared data in GDC]
 +
 
 +
=== Proposals ===
 +
* [http://wiki.dlang.org/DIP62 DIP62]
 +
* [http://wiki.dlang.org/DIP20 DIP20]
 +
** [http://forum.dlang.org/post/k54gc2$428$1@digitalmars.com October 2012 Discussion]
 +
* [http://wiki.dlang.org/DIP17 DIP17] - Superceded by [http://wiki.dlang.org/DIP20 DIP20]
 +
 
 +
== <code>final</code>-by-default ==
 +
=== Threads ===
 +
* [http://forum.dlang.org/post/lfqoan$5qq$1@digitalmars.com March 2014 Discussion]
 +
* [http://forum.dlang.org/post/yzsqwejxqlnzryhrkfuq@forum.dlang.org May 2013 Discussion]
 +
 
 +
=== Essential Moments ===
 +
* [http://forum.dlang.org/post/mailman.797.1370344528.13711.digitalmars-d@puremagic.com Manu provides justification for <code>final</code>-by-default]
 +
* [http://forum.dlang.org/post/koqkhc$4nn$1@digitalmars.com Walter concedes]
 +
* [http://forum.dlang.org/post/lfqoan$5qq$1@digitalmars.com Walter posts decision] citing [http://forum.dlang.org/post/lfgot7$8lg$1@digitalmars.com JSON regression] and almost losing a client. 
 +
** [http://forum.dlang.org/post/xbbzknslhfrwlwoqfcak@forum.dlang.org Client affected by JSON regression steps forward] encouraging gradual, managed change
 +
* [http://forum.dlang.org/post/lfrdst$oav$1@digitalmars.com Andrei puts his foot down] stating there will be no <code>final</code>-by-default in the D programming language.
 +
 
 +
== rvalue references ==
 +
=== Threads ===
 +
* [http://forum.dlang.org/post/kl4v8r$tkc$1@digitalmars.com April 2013 Discussion]
 +
* [http://forum.dlang.org/post/4F84D6DD.5090405@digitalmars.com April 2012 Discussion]
 +
* [http://d.puremagic.com/issues/show_bug.cgi?id=9238 Issue Report]
 +
 
 +
 
 +
 
 +
== Inherited constructors ==
 +
==== Description ====
 +
When inheriting a class, the new class does not inherit its constructors. Any base class constructors need to be manually forwarded to. A library solution to automatically mix-in forwarding constructors is possible, but a language solution is possible too.
 +
 
 +
Note that C++11 supports [http://en.wikipedia.org/wiki/C++11#Object_construction_improvement this feature].
 +
 
 +
==== Threads ====
 +
* [http://forum.dlang.org/post/ddjpmg$239v$1@digitaldaemon.com August 2005 Discussion]
 +
* [http://forum.dlang.org/post/op.tocyirzyusumhd@mist February 2007 Discussion]
 +
* [http://forum.dlang.org/post/f3pisd$4vi$3@digitalmars.com June 2007 Discussion]
 +
* [http://forum.dlang.org/post/fqk4jb$n76$1@digitalmars.com March 2008 Discussion]
 +
* [http://forum.dlang.org/post/heuuk9$1nfq$1@digitalmars.com November 2009 Discussion]
 +
* [http://forum.dlang.org/post/i3etqg$1o8s$1@digitalmars.com August 2010 Discussion]
 +
 
 +
=== Bug reports ===
 +
* [https://issues.dlang.org/show_bug.cgi?id=9066 Issue 9066 -  Add constructor inheritance feature]
 +
 
 +
 
 +
 
 +
 
 +
== Automatic Reference Counting (ARC) as an alternative to D's Garbage Collector ==
 +
=== Threads ===
 +
* [http://forum.dlang.org/post/l34lei$255v$1@digitalmars.com Walter's October 2013 Draft Proposal and Discussion]
 +
 
 +
=== Essential Moments ===
 +
Sonke Ludwig posted a nice summary of the thread that shows up 3/4 of the way through:
 +
 
 +
http://forum.dlang.org/post/l3bkve$ur8$1@digitalmars.com
 +
 
 +
Here's a repost of the contents:
 +
 
 +
I've made short roundup of the different features/requirements that have
 +
been mentioned (may have forgotten some and added some) as this thread
 +
has a complexity that presumably makes it quite hard to follow for most
 +
readers. I have also attached an estimated priority for each requirement
 +
based on the discussion and my own experiences.
 +
 
 +
- Memory safety [very important but also very difficult/limiting]
 +
    Disallow escaping uncounted references to reference counted
 +
    memory. Keywords: pure, scope, isolated/owned
 +
- COM compatible [important]
 +
    Needs to support internal reference counting using
 +
    AddRef/ReleaseRef, while obeying to the call convention
 +
- Objective-C compatible [important]
 +
    Weak references, manual memory management and autorelease pools are
 +
    some keywords here
 +
- Handle reference cycles [nice to have]
 +
    Requires GC memory for storing the instances
 +
- Weak pointers [critical]
 +
    Only briefly mentioned, but critical for many data structures
 +
    (e.g. graphs or caches) requires external reference counting
 +
- Not require two separate counts for COM [mildly important]
 +
    Using GC memory would require a second reference count for the
 +
    D side of things, which is not desirable for multiple reasons
 +
- Support type qualifiers [critical]
 +
    All usual type qualifiers and conversions should work as expected.
 +
    This is not possible in a pure template based solution.
 +
- Support non-class types [nice to have]
 +
    Although slightly limiting, classes provide a convenient
 +
    abstraction and will arguably capture >90% use cases just fine
 +
- Support referencing fields/slices [nice to have]
 +
    Letting references to members escape in a safe way would greatly
 +
    increase the flexibility, but ties it tightly to the GC
 +
- Allow manual memory management [critical]
 +
    For COM/Obj-C and any situation where external code is to take
 +
    responsibility of the ref counting this needs to be an option
 +
- Not require new annotations [important]
 +
    Getting this to work without introducing new keywords/syntax is
 +
    strongly preferred by Walter
 +
- Safe shared(RefCountedType) variables [important]
 +
    There needs to be a way to make shared references thread-safe
 +
- Support OOP reasonably well [important]
 +
    The usual up and down casts should work and calling functions of
 +
    base classes needs to be safe
 +
 
 +
Please mention any points that I have forgotten so that we have some
 +
kind of unit test against which proposed designs can be checked.
 +
[[Category:Proposals]]

Latest revision as of 21:39, 20 May 2015

D is an evolving and complex language. New features are proposed, unexpected interaction in old ones get found, design issues are raised. All this may involve hard debates in D newsgroup and if often forgotten. This page serves as an index for major design discussions and proposals.

Formal improvement proposals can be found on the main DIP index.


Properties

Description

Initial @property design has issues. How can it be changed or even discarded at all?

Thread

Essential moments

Property Discussion Wrap-up

Proposals


Access specifiers and symbol visibility

Description

Currently there is feature like "static global" in C or "unnamed namespace" in C++. Access specifiers for module-level symbols control access, not visibility. Ability to hide symbols needs to be added without breaking current access system.

As a result of discussion, Walter has asked for DIP on this topic.

Essential moments

Thread

Proposal

DIP22


auto ref

Description

Essential moments

Thread


volatile

Threads

Essential Moments

Proposals

final-by-default

Threads

Essential Moments

rvalue references

Threads


Inherited constructors

Description

When inheriting a class, the new class does not inherit its constructors. Any base class constructors need to be manually forwarded to. A library solution to automatically mix-in forwarding constructors is possible, but a language solution is possible too.

Note that C++11 supports this feature.

Threads

Bug reports



Automatic Reference Counting (ARC) as an alternative to D's Garbage Collector

Threads

Essential Moments

Sonke Ludwig posted a nice summary of the thread that shows up 3/4 of the way through:

http://forum.dlang.org/post/l3bkve$ur8$1@digitalmars.com

Here's a repost of the contents:

I've made short roundup of the different features/requirements that have been mentioned (may have forgotten some and added some) as this thread has a complexity that presumably makes it quite hard to follow for most readers. I have also attached an estimated priority for each requirement based on the discussion and my own experiences.

- Memory safety [very important but also very difficult/limiting]
    Disallow escaping uncounted references to reference counted
    memory. Keywords: pure, scope, isolated/owned
- COM compatible [important]
    Needs to support internal reference counting using
    AddRef/ReleaseRef, while obeying to the call convention
- Objective-C compatible [important]
    Weak references, manual memory management and autorelease pools are
    some keywords here
- Handle reference cycles [nice to have]
    Requires GC memory for storing the instances
- Weak pointers [critical]
    Only briefly mentioned, but critical for many data structures
    (e.g. graphs or caches) requires external reference counting
- Not require two separate counts for COM [mildly important]
    Using GC memory would require a second reference count for the
    D side of things, which is not desirable for multiple reasons
- Support type qualifiers [critical]
    All usual type qualifiers and conversions should work as expected.
    This is not possible in a pure template based solution.
- Support non-class types [nice to have]
    Although slightly limiting, classes provide a convenient
    abstraction and will arguably capture >90% use cases just fine
- Support referencing fields/slices [nice to have]
    Letting references to members escape in a safe way would greatly
    increase the flexibility, but ties it tightly to the GC
- Allow manual memory management [critical]
    For COM/Obj-C and any situation where external code is to take
    responsibility of the ref counting this needs to be an option
- Not require new annotations [important]
    Getting this to work without introducing new keywords/syntax is
    strongly preferred by Walter
- Safe shared(RefCountedType) variables [important]
    There needs to be a way to make shared references thread-safe
- Support OOP reasonably well [important]
    The usual up and down casts should work and calling functions of
    base classes needs to be safe

Please mention any points that I have forgotten so that we have some kind of unit test against which proposed designs can be checked.