|
|
| (4 intermediate revisions by the same user not shown) |
| Line 24: |
Line 24: |
| | |- | | |- |
| | |Links: | | |Links: |
| | + | | [http://forum.dlang.org/post/ydyqguthbfxlnuxtqklx@forum.dlang.org] [https://github.com/Dgame/dmd/tree/static_array_literals implementation in progress] |
| | | | | | |
| | |} | | |} |
| Line 37: |
Line 38: |
| | == Description == | | == Description == |
| | Currently, array literals such as | | Currently, array literals such as |
| | + | <syntaxhighlight lang="d"> |
| | auto x=[1,2,3]; | | auto x=[1,2,3]; |
| | + | </syntaxhighlight> |
| | make x dynamic. To get a static array one needs to write: | | make x dynamic. To get a static array one needs to write: |
| | + | <syntaxhighlight lang="d"> |
| | int[3] x=[1,2,3]; | | int[3] x=[1,2,3]; |
| | + | </syntaxhighlight> |
| | which is inconvenient for many reasons: | | which is inconvenient for many reasons: |
| − | * DRY principle (need to explicitly write 3 as the length and specify the type | + | * it's not DRY (need to explicitly write 3 as the length and specify the type int) |
| − | int) | + | * there's no easy way to pass a static array literal to a function accepting a static array; for example it requires: |
| − | * no easy way to pass a static array litteral to a function accepting a static | + | <syntaxhighlight lang="d"> |
| − | array; for example it requires: | |
| | int[3] x=[1,2,3]; | | int[3] x=[1,2,3]; |
| | fun(x); | | fun(x); |
| | + | </syntaxhighlight> |
| | | | |
| − | | + | Instead we propose the syntax: |
| − | Wouldn't it be simple to allow writing array literals using the syntax:
| |
| − | auto x=[1,2,3]S;
| |
| − | where S stands for static?
| |
| − | More generally the compiler should translate [x1,...,xn]S to: typeof(x1)[n]
| |
| − | | |
| − | Advantages:
| |
| − | * static array litterals becomes as convenient as dynamic ones
| |
| − | * no confusion possible for the compiler; I believe this syntax doesn't clash
| |
| − | with existing syntax.
| |
| − | * In our previous example, no need to write an intermediate x: we can just
| |
| − | write
| |
| − | fun([1,2,3]S);
| |
| − | or
| |
| − | fun([1.0,2,3]S); //for example, if static array of doubles requested
| |
| − | | |
| − | * this would also prevent the common workaround hacks of the form:
| |
| − | void fun(T...)(T x){} which accept fun(1,2,3): one could just write:
| |
| − | void fun(T,uint N)(in T[N]x){} or void fun(T,uint N)(T[N]x){}
| |
| − | | |
| − | * this could prevent inefficient intermediate code as reported in Issue 2356
| |
| − | and related, as it would be clear from "S" that a static is requested.
| |
| − | | |
| − | * this could be used in expressions as well: auto x=[1,2,3]S+[4,5,6]S;
| |
| − | | |
| − | This should be simpler than a previous request I've seen for int[$]x=[1,2,3];,
| |
| − | which still requires one to write the type explicitly.
| |
| − | | |
| − | | |
| − | == Abstract ==
| |
| − | Safe references and rvalue references without runtime checks.
| |
| | <syntaxhighlight lang="d"> | | <syntaxhighlight lang="d"> |
| | auto x=[1,2,3]S; | | auto x=[1,2,3]S; |
| − | static assert(is(typeof(x)==int[3]));
| |
| | </syntaxhighlight> | | </syntaxhighlight> |
| − | The particular choice of 'S' can be discussed.
| + | where S stands for static. More generally the compiler should translate |
| − | | |
| − | == Description ==
| |
| − | Dconf13 introduced safe references enabled by a runtime check (see email thread from Walter: 'Rvalue references - The resolution'). I propose a formulation that is safe, yet doesn't require any runtime check.
| |
| − | The compiler automatically annotates any return by ref function with a dependency on input arguments:
| |
| − | | |
| − | eg:
| |
| | <syntaxhighlight lang="d"> | | <syntaxhighlight lang="d"> |
| − | | + | [x1,...,xn]S to: typeof(x1)[n] |
| − | struct U{T x;}
| |
| − | ref T foo(ref T a, ref T b, ref U c, T d){
| |
| − | if(condition)
| |
| − | return a;
| |
| − | else if(condition(b))
| |
| − | return c.x;
| |
| − | else
| |
| − | return d;
| |
| − | }
| |
| | </syntaxhighlight> | | </syntaxhighlight> |
| | | | |
| − | will be rewritten internally by the compiler as having the signature:
| + | Advantages: |
| | + | * static array literals becomes as convenient as dynamic ones |
| | + | * no confusion possible for the compiler; I believe this syntax doesn't clash with existing syntax. |
| | + | * In our previous example, no need to write an intermediate x: we can just write |
| | <syntaxhighlight lang="d"> | | <syntaxhighlight lang="d"> |
| − | ref(0,2) T foo(ref T a, ref T b, ref T c, T d);
| + | fun([1,2,3]S); |
| | + | fun([1.0,2,3]S); //for example, if static array of doubles requested |
| | </syntaxhighlight> | | </syntaxhighlight> |
| − | indicating that ref depends on ref arguments 0(a) and 2 (c) (dependency on c is via field access). The other arguments are not in the list because they're not input ref arguments, or not returned.
| |
| − |
| |
| − | Second example: when the function is a member (say of a struct), the 'this' parameter is implicitly argument number 0, but the same rules apply:
| |
| | | | |
| | + | * this would also prevent the common workaround hacks of the form: |
| | <syntaxhighlight lang="d"> | | <syntaxhighlight lang="d"> |
| − | struct S { T t; ref T fooc(ref T a) { if(condition) return t; else return a;} }
| + | void fun(T...)(T x){} which accept fun(1,2,3): one could just write: |
| | + | void fun(T,uint N)(in T[N]x){} or void fun(T,uint N)(T[N]x){} |
| | </syntaxhighlight> | | </syntaxhighlight> |
| | | | |
| − | will be rewritten internally by the compiler as having the signature:
| + | * this could prevent inefficient intermediate code as reported in Issue 2356 and related, as it would be clear from "S" that a static is requested. |
| | | | |
| − | <syntaxhighlight lang="d">
| + | * this could be used in expressions as well: auto x=[1,2,3]S+[4,5,6]S; |
| − | struct S { T t; ref(0,1) T fooc(ref T a); }
| |
| − | </syntaxhighlight>
| |
| − | because there's a ref dependency on 0(this) and 1(a).
| |
| − | | |
| − | Note, if there's no dependency on input ref arguments (for example, it returns by ref a global), then the ref list is empty, ie ref().
| |
| − | | |
| − | Given those compiler generated annotations, it is easy to validate/invalidate ref safety:
| |
| − | the rule is: in any return statement of a ref-return function, the ref dependency list can only refer to:
| |
| − | A) global variables (gc-alloced, static etc)
| |
| − | B) ref inputs
| |
| − | | |
| − | This excludes locals.
| |
| − | | |
| − | Examples: taken from Walter's above mentioned email:
| |
| − | | |
| − | <syntaxhighlight lang="d">
| |
| − | | |
| − | //Case A:
| |
| − | ref T fooa(ref T t) { return t; }
| |
| − | //=> ref(0) T fooa(ref T t);
| |
| − | ref T bar() { T t; return ref fooa(t); } // error since 0 refers to t which is a local
| |
| − | | |
| − | //Case B:
| |
| − | ref(u) T foob(ref U u) { return u.t; } // note that T is derivable from U
| |
| − | ref U bar() { T t; return ref(t) foob(t); }
| |
| − | | |
| − | //Case C:
| |
| − | struct S { T t; ref(this) T fooc() { return t; } }
| |
| − | ref T bar() { S s; return ref(s) s.fooc(); }
| |
| − | | |
| − | //Case D:
| |
| − | Returning ref to uplevel local:
| |
| − | | |
| − | ref T food() {
| |
| − | T t;
| |
| − | ref(t) T bar() { return t; }
| |
| − | return ref(t) bar();
| |
| − | }
| |
| − | | |
| − | //case E:
| |
| − | Transitively calling other functions:
| |
| − | | |
| − | ref T fooe(T t) { return ref(t) fooa(t); }
| |
| − | | |
| − | </syntaxhighlight>
| |
| − | | |
| − | | |
| − | Final point: the di files will have to write those annotations written down, which shall be done automatically.
| |
| − | | |
| − | == Usage ==
| |
| − | <div style="padding: 1ex 1ex; background: #ffd;">This section has been adapted for MediaWiki.</div>
| |
| − | | |
| − | To start a new DIP you can go to Edit link and copy the source of this DIP, then go to [[DIPs|DIP index]] and add a new item in the list. The DIP number should be one more than the last DIP in the index (for example, if the DIP1 is the last DIP, your DIP should be DIP2). The link in the index should have the form: <nowiki>[[DIPx]]</nowiki>, Title, Status, resume. Where x is the DIP number, title is the DIP title and resume is a short description about the DIP.
| |
| − | | |
| − | Save the [[DIPs|DIP index]] page and click on the new red link. Now you are editing the new DIP you just created, now paste the copied source text from this template and replace all the you need.
| |
| − | | |
| − | Remember to update the metadata at the start of the DIP, and keep it as a Draft at the beginning. When your DIP is done, you should announce it in the News Group for discussion, with a subject like this: new DIPx: title (where one more time x is the DIP number and title is the DIP title).
| |
| − | | |
| − | You should always put you DIPs in the Public Domain (or a similarly permissive license but use Public Domain unless you're very sure of what you're doing).
| |
| − | | |
| − | == Recommendations ==
| |
| − | When writing a DIP, try not to express your opinion. DIPs should provide facts and be as objective as possible. Even when that's pretty hard, you can make the DIP look more objective by not using, for example, "I prefer XXX because YYY". If YYY is an objective advantage, write that in a more objective way, like "XXX can be a better option because YYY". Try to leave non-technical personal preferences aside; "XXX can be a better option because the syntax is nicer" is not good enough even when you don't say "I prefer".
| |
| − | | |
| − | Try not to include half-baked ideas. If you are not sure about something, leave it outside the DIP and write it on the NG announcement instead for further discussion. The idea can be added to the DIP in the future when it is in a better shape.
| |
| − | | |
| − | == Abstract ==
| |
| − | Make the abstract as descriptive as possible (while keeping it brief). From an abstract you should be able to tell what the DIP is about, you should introduce for every non-trivial concept a person should know for understanding the DIP (or provide links if you can't briefly describe those concepts in the abstract). Don't copy the title of the DIP to use it as an abstract. Ideally an abstract should be a paragraph 5 to 10 lines long.
| |
| − | | |
| − | == Rationale ==
| |
| − | Rationale should be complete. When the DIP tries to solve a problem, try to describe that problem as detailed as possible. If you have links to the NG describing the problem more deeply, used them. All the background information is welcome.
| |
| − | | |
| − | == NG Announcement ==
| |
| − | When posting the DIP announcement to the NG, please copy the abstract, so people can easily know what is it about and follow the link if they are interested.
| |
| | | | |
| | + | This should be simpler than a previous request I've seen for int[$]x=[1,2,3]; which still requires one to write the type explicitly. |
| | | | |
| | == Copyright == | | == Copyright == |
DIP34: Static array literals (STILL EDITING -- don't read yet)
| Title:
|
Static array literals
|
| DIP:
|
34
|
| Version:
|
1
|
| Status:
|
Draft
|
| Created:
|
2013-04-06
|
| Last Modified:
|
2013-04-06
|
| Author:
|
Timothee Cour
|
| Links:
|
[1] implementation in progress
|
|
Abstract
This is a proposal for introducing static array literals, as follows:
auto x=[1,2,3]S;
static assert(is(typeof(x)==int[3]));
The particular choice of 'S' can be discussed.
Description
Currently, array literals such as
make x dynamic. To get a static array one needs to write:
which is inconvenient for many reasons:
* it's not DRY (need to explicitly write 3 as the length and specify the type int)
* there's no easy way to pass a static array literal to a function accepting a static array; for example it requires:
int[3] x=[1,2,3];
fun(x);
Instead we propose the syntax:
where S stands for static. More generally the compiler should translate
[x1,...,xn]S to: typeof(x1)[n]
Advantages:
* static array literals becomes as convenient as dynamic ones
* no confusion possible for the compiler; I believe this syntax doesn't clash with existing syntax.
* In our previous example, no need to write an intermediate x: we can just write
fun([1,2,3]S);
fun([1.0,2,3]S); //for example, if static array of doubles requested
- this would also prevent the common workaround hacks of the form:
void fun(T...)(T x){} which accept fun(1,2,3): one could just write:
void fun(T,uint N)(in T[N]x){} or void fun(T,uint N)(T[N]x){}
- this could prevent inefficient intermediate code as reported in Issue 2356 and related, as it would be clear from "S" that a static is requested.
- this could be used in expressions as well: auto x=[1,2,3]S+[4,5,6]S;
This should be simpler than a previous request I've seen for int[$]x=[1,2,3]; which still requires one to write the type explicitly.
Copyright
This document has been placed in the Public Domain.
