Difference between revisions of "Language design discussions"

From D Wiki
Jump to: navigation, search
(Added DIP62 to 'volatile' discussion)
 
(4 intermediate revisions by one other user not shown)
Line 51: Line 51:
  
 
=== Threads ===
 
=== 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/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/mailman.921.1378464218.1719.d.gnu@puremagic.com September 2013 Discussion]
Line 60: Line 62:
  
 
=== Essential Moments ===
 
=== 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.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]
 
* [http://forum.dlang.org/post/mailman.2454.1382619958.1719.digitalmars-d@puremagic.com compiler does not cache shared data in GDC]
Line 76: Line 79:
 
=== Essential Moments ===
 
=== 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/mailman.797.1370344528.13711.digitalmars-d@puremagic.com Manu provides justification for <code>final</code>-by-default]
* [http://forum.dlang.org/post/mailman.797.1370344528.13711.digitalmars-d@puremagic.com Walter concedes]
+
* [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/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/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.
 
* [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 ==
 
== rvalue references ==
Line 168: Line 169:
 
Please mention any points that I have forgotten so that we have some  
 
Please mention any points that I have forgotten so that we have some  
 
kind of unit test against which proposed designs can be checked.
 
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.