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.
- 1 Properties
- 2 Access specifiers and symbol visibility
- 3 auto ref
- 4 volatile
- 5 final-by-default
- 6 rvalue references
- 7 Inherited constructors
- 8 Automatic Reference Counting (ARC) as an alternative to D's Garbage Collector
Initial @property design has issues. How can it be changed or even discarded at all?
- Initial discussion where this topic has rised
- Walters follow-up with proposal to kill property, most info here
Access specifiers and symbol visibility
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.
- 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
- 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
- Walter implements peek/poke intrinsics discouraging continued discussion on DIP62
sharedconsidered a volatile type in GDC, more more
- compiler does not cache shared data in GDC
- Manu provides justification for
- 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.
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.
- August 2005 Discussion
- February 2007 Discussion
- June 2007 Discussion
- March 2008 Discussion
- November 2009 Discussion
- August 2010 Discussion
Automatic Reference Counting (ARC) as an alternative to D's Garbage Collector
Sonke Ludwig posted a nice summary of the thread that shows up 3/4 of the way through:
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.