Language design discussions

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

• Initial discussion where this topic has rised
• Walters follow-up with proposal to kill property, most info here

Essential moments

Property Discussion Wrap-up

Proposals

• 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

• Walter's final resolution about topics to cover in DIP

Thread

• Initial thread that has raised this topic
• Follow-up about current state of affairs
• Access specifiers and visibility - combined data to make a decision upon

Proposal

DIP22

auto ref

Thread

• auto ref - again

volatile

Threads

• July 2014 Discussion
• May~June 2014 Discussion
• October 2013 Discussion
• September 2013 Discussion
• July 2012 Discussion
• July 2004 Discussion
• June 2004 Discussion
• May 2004 Discussion
• March 2002 Discussion

Essential Moments

• Walter implements peek/poke intrinsics discouraging continued discussion on DIP62
• shared considered a volatile type in GDC, more more
• compiler does not cache shared data in GDC

Proposals

• DIP62
• DIP20
  • October 2012 Discussion
• DIP17 - Superceded by DIP20

final-by-default

Threads

• March 2014 Discussion
• May 2013 Discussion

Essential Moments

• Manu provides justification for final-by-default
• Walter concedes
• Walter posts decision citing JSON regression and almost losing a client.
  • Client affected by JSON regression steps forward encouraging gradual, managed change
• Andrei puts his foot down stating there will be no final-by-default in the D programming language.

rvalue references

Threads

• April 2013 Discussion
• April 2012 Discussion
• 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 this feature.

Threads

• August 2005 Discussion
• February 2007 Discussion
• June 2007 Discussion
• March 2008 Discussion
• November 2009 Discussion
• August 2010 Discussion

Bug reports

• Issue 9066 - Add constructor inheritance feature

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

Threads

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