On 08/22/2016 08:22 PM, H. S. Teoh via Digitalmars-d wrote:
>> 3. separate compilation
>
> Under the current state of separate compilation, yes. But in theory it
> *should* be possible, at least in some of the common use cases.
Separate compilation is perfectly fixable if we agree for it to
On Mon, Aug 22, 2016 at 06:02:20PM +, Meta via Digitalmars-d wrote:
> On Monday, 22 August 2016 at 17:22:28 UTC, H. S. Teoh wrote:
> > I think it should be possible even with recursion, at least if there
> > is a non-recursive branch in the function(s). Of course, it may not
> > necessarily be
On Monday, 22 August 2016 at 17:22:28 UTC, H. S. Teoh wrote:
I think it should be possible even with recursion, at least if
there is a non-recursive branch in the function(s). Of course,
it may not necessarily be *feasible* to implement the required
analysis in the compiler. But maybe for the
On Mon, Aug 15, 2016 at 04:46:15PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/15/2016 4:30 PM, H. S. Teoh via Digitalmars-d wrote:
> > I'm looking forward to the day we have pervasive attribute
> > inferrence throughout the language. It's the only sane way to deal
> > with attributes,
On 08/12/2016 01:24 PM, Robert burner Schadek wrote:
>> No, the DIP doesn't handle several levels of indirection.
>
> What about:
>
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
>
> fcs["bar"].a = 1337; // log n
> fcs["bar"].b = 1338; // log n
>
> ? I need to pay
On 8/15/2016 4:30 PM, H. S. Teoh via Digitalmars-d wrote:
I'm looking forward to the day we have pervasive attribute inferrence
throughout the language. It's the only sane way to deal with
attributes, because they inevitably grow unmanageably numerous. In an
ideal world I'd say *all* attributes
On Mon, Aug 15, 2016 at 02:43:01PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/15/2016 7:48 AM, Chris Wright wrote:
> > Oh god, the attribute explosion is getting worse.
> >
> > I think at this point the proper way to use attribute-based D
> > features is to write your code without them,
On 8/15/2016 7:48 AM, Chris Wright wrote:
Oh god, the attribute explosion is getting worse.
I think at this point the proper way to use attribute-based D features is
to write your code without them, then write a tool that will add all the
attributes to your source code that it can while not
public final void foo() scope inout @nogc nothrow @safe pure {}
I think the solution is to turn every function into a no-args
template, but then you can't use virtual methods.
** sarcasm on **
Don't say that, you give them ideas ;-)
** sarcasm off **
On Mon, 15 Aug 2016 06:36:00 -0700, Walter Bright wrote:
> If the method is annotated with scope, the scope applies to the 'this'
> pointer.
Oh god, the attribute explosion is getting worse.
I think at this point the proper way to use attribute-based D features is
to write your code without
On 8/15/2016 5:17 AM, Dicebot wrote:
On 08/15/2016 02:52 PM, Walter Bright wrote:
On 8/15/2016 2:32 AM, Kagamin wrote:
On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
auto r = range;
You said that if a value (range in this case) is returned by scope,
its lifetime
is
On 08/15/2016 02:52 PM, Walter Bright wrote:
> On 8/15/2016 2:32 AM, Kagamin wrote:
>> On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
>>> auto r = range;
>>
>> You said that if a value (range in this case) is returned by scope,
>> its lifetime
>> is restricted to its expression,
On 8/15/2016 2:32 AM, Kagamin wrote:
On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
auto r = range;
You said that if a value (range in this case) is returned by scope, its lifetime
is restricted to its expression, hence it can't be assigned to a variable,
because the variable
On 08/15/2016 12:32 PM, Kagamin wrote:
> On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
>> auto r = range;
>
> You said that if a value (range in this case) is returned by scope, its
> lifetime is restricted to its expression, hence it can't be assigned to
> a variable, because
On Sunday, 14 August 2016 at 20:02:35 UTC, Walter Bright wrote:
auto r = range;
You said that if a value (range in this case) is returned by
scope, its lifetime is restricted to its expression, hence it
can't be assigned to a variable, because the variable outlives
the expression.
On 8/14/2016 2:12 PM, Dicebot wrote:
On 08/14/2016 10:50 PM, Walter Bright wrote:
Hmm, but we've always done warning => deprecation => error
Yes, and it was a major disaster because most sensible projects compile
with warnings as errors enabled (it is also the default in dub) and thus
putting
On 08/14/2016 10:50 PM, Walter Bright wrote:
> On 8/14/2016 7:42 AM, Dicebot wrote:
>> Two another more nitpicky comments:
>>
>> 1) Deprecation process proposal right now says this:
>>
>> - remove -scope, issue warning when errors are detected
>> - replace warnings with deprecation messages
>>
>>
On 08/14/2016 11:02 PM, Walter Bright wrote:
> It's a bit advanced, but it falls entirely in the DIP rules and is
> workable with some implementation effort (not sure how much).
>
> The idea is, if something is ultimately a stack variable, the scope
> rules apply.
That is an unexpected
On 8/14/2016 7:37 AM, Dicebot wrote:
struct Container
{
int data;
static struct Range
{
int* pdata;
// range methods skipped for clarity ..
}
Range asRange ( )
{
return Range();
}
}
void main ( )
{
Container container;
import
On 8/14/2016 7:42 AM, Dicebot wrote:
Two another more nitpicky comments:
1) Deprecation process proposal right now says this:
- remove -scope, issue warning when errors are detected
- replace warnings with deprecation messages
PLEASE FOR THE SAKE OF ALL DEAR NEVER EVER DO THIS
Deprecations
On 8/14/2016 12:39 PM, Walter Bright wrote:
On 8/14/2016 7:42 AM, Dicebot wrote:
2) Ignoring `scope` for variables with no indirections.
The fact that DMD is extremely accepting when it comes to nonsense
declarations/attributes has been is notable contribution to harming
learning curve. It
On 8/14/2016 7:42 AM, Dicebot wrote:
2) Ignoring `scope` for variables with no indirections.
The fact that DMD is extremely accepting when it comes to nonsense
declarations/attributes has been is notable contribution to harming
learning curve. It often tricks new developers into thinking that
Two another more nitpicky comments:
1) Deprecation process proposal right now says this:
- remove -scope, issue warning when errors are detected
- replace warnings with deprecation messages
PLEASE FOR THE SAKE OF ALL DEAR NEVER EVER DO THIS
Deprecations must always come first. Warnings may or
On 08/10/2016 11:36 PM, Dicebot wrote:
> http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
I am still uncertain myself about the proposal, mostly because can't
completely grasp rules for returning as scope. My litmus test example is
very simple (for desired semantics):
```
struct
On 08/13/2016 12:16 PM, deadalnix wrote:
I suggested various changes int he DIP, which I'm copying bellow.
That's the spirit. Thanks. -- Andrei
On Saturday, 13 August 2016 at 14:35:09 UTC, Andrei Alexandrescu
wrote:
You have the detail in your inbox for close to 2 years now.
Thanks. Do you have a date or title of the thread? -- Andrei
In the very thread that ended up with DIP1000 .
I suggested various changes int he DIP, which I'm
On 08/13/2016 03:25 AM, deadalnix wrote:
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing from these
conversation because I have no idea how to reach to you guys.
You committed
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu
wrote:
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing from
these
conversation because I have no idea how to reach to you guys.
You committed to author a proposal a few months back.
On Friday, 12 August 2016 at 21:36:20 UTC, Andrei Alexandrescu
wrote:
Can you please give examples of cases that are (a) unlikely to
be supported with reasonable effort, and (b) likely to cause
problems in usability? Thanks! -- Andrei
Anythign that work with a linkedlist or a tree structure.
On 8/12/2016 2:03 PM, Timon Gehr wrote:
On 12.08.2016 22:22, Walter Bright wrote:
I believe it does track across function boundaries, because function
parameters can be annotated.
Yes, to some extent, but what the type system knows and makes use of at the call
site is more informative than
On 08/12/2016 04:58 PM, Timon Gehr wrote:
On 12.08.2016 22:22, Andrei Alexandrescu wrote:
On 08/12/2016 03:34 PM, Timon Gehr wrote:
On 10.08.2016 22:36, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
On 12.08.2016 22:22, Walter Bright wrote:
On 8/12/2016 12:34 PM, Timon Gehr wrote:
This proposes to add a kind of information the type system is supposed
to track
(lifetimes), which cannot be communicated losslessly across function and
aggregate boundaries. Hence it won't work well in its
On 12.08.2016 22:22, Andrei Alexandrescu wrote:
On 08/12/2016 03:34 PM, Timon Gehr wrote:
On 10.08.2016 22:36, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it
On 08/12/2016 03:34 PM, Timon Gehr wrote:
On 10.08.2016 22:36, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it bypasses usual nitpicking process and
proceeds
On 8/12/2016 12:34 PM, Timon Gehr wrote:
This proposes to add a kind of information the type system is supposed to track
(lifetimes), which cannot be communicated losslessly across function and
aggregate boundaries. Hence it won't work well in its current form.
I believe it does track across
On 8/11/2016 1:53 AM, John Colvin wrote:
On Thursday, 11 August 2016 at 08:45:38 UTC, Walter Bright wrote:
On 8/11/2016 1:29 AM, John Colvin wrote:
Can someone talk me through the lifetime algebra for the following?
void foo()
{
int a;
int** c;
void bar()
{
int* b =
On 8/12/2016 12:45 PM, Timon Gehr wrote:
Assuming all the soundness issues are fixed, I think the general scheme it is
not expressive enough.
Possibly true, but general expressivity comes at a large cost in complexity and
difficulty for users.
E.g. it does not allow lazy range algorithms
On 11.08.2016 12:13, Walter Bright wrote:
On 8/11/2016 3:00 AM, deadalnix wrote:
This DIP is flawed because it only handle on
indirection level and break down for anything more than this.
It actually does two levels - the address of the pointer variable
('ref') and the contents of the pointer
On 10.08.2016 22:36, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it bypasses usual nitpicking process and
proceeds straight to requesting community (your!)
On Fri, Aug 12, 2016 at 01:27:08PM +, Kagamin via Digitalmars-d wrote:
> On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
> > > auto arr = RefCountedSlice!int(10);
> > > auto ptr = [5];
> > > arr = RefCountedSlice!int(42);
> > > *ptr = 1;// use after free
> >
> > The idea
On Friday, 12 August 2016 at 14:02:50 UTC, Chris Wright wrote:
In the worst case, you can change the API so you can write:
rcs.update("bar", (x) { x.a = 1337; x.b = 1338; });
yes, but that will not catch on. And I think (x) must be (scope
ref x)
On Fri, 12 Aug 2016 10:24:22 +, Robert burner Schadek wrote:
>> No, the DIP doesn't handle several levels of indirection.
>
> What about:
>
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
>
> fcs["bar"].a = 1337; // log n
> fcs["bar"].b = 1338; // log n
>
> ? I
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
auto arr = RefCountedSlice!int(10);
auto ptr = [5];
arr = RefCountedSlice!int(42);
*ptr = 1;// use after free
The idea is to have containers return references by 'return
ref' or 'return scope' so the internal references
On Thursday, 11 August 2016 at 08:53:22 UTC, John Colvin wrote:
On Thursday, 11 August 2016 at 08:45:38 UTC, Walter Bright
wrote:
On 8/11/2016 1:29 AM, John Colvin wrote:
Can someone talk me through the lifetime algebra for the
following?
void foo()
{
int a;
int** c;
void bar()
On Friday, 12 August 2016 at 12:41:07 UTC, Andrei Alexandrescu
wrote:
On 8/12/16 8:28 AM, Seb wrote:
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu
wrote:
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing
from these
conversation
On 8/12/16 8:28 AM, Seb wrote:
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing from these
conversation because I have no idea how to reach to you guys.
You committed to author
On 8/12/16 8:28 AM, Seb wrote:
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing from these
conversation because I have no idea how to reach to you guys.
You committed to author
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu
wrote:
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing from
these
conversation because I have no idea how to reach to you guys.
You committed to author a proposal a few months back.
On 8/12/16 6:12 AM, deadalnix wrote:
To be honest I'm to a point were I'm starting withdrawing from these
conversation because I have no idea how to reach to you guys.
You committed to author a proposal a few months back. Did you make
progress on that? -- Andrei
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
On 8/11/2016 6:36 AM, Marc Schütz wrote:
4) The DIP doesn't address mutable aliasing at all. As a
consequence, the
example `RefCountedSlice` is unsafe:
auto arr = RefCountedSlice!int(10);
auto ptr = [5];
arr =
On 8/12/2016 3:24 AM, Robert burner Schadek wrote:
? I need to pay log n twice to assign two members
In order to return a pointer that lasts longer than an expression, make it a ref
counted entity as well.
On Friday, 12 August 2016 at 10:24:22 UTC, Robert burner Schadek
wrote:
No, the DIP doesn't handle several levels of indirection.
What about:
struct Bar { int a; int b }
auto rcs = RefCountedTree!(string,Bar)();
fcs["bar"].a = 1337; // log n
fcs["bar"].b = 1338; // log n
? I need to pay
On 8/12/2016 2:42 AM, Robert burner Schadek wrote:
Hm, that is really bad IMO. The shown use case is properly the most common use
case. Is there no way to make it transitive so the lifetime of rcs[0] is the
lifetime of rcs.
rcs[0].a = 1337;
assert(rcs[0].a == 1337);
It shouldn't be a big
On 8/12/2016 3:12 AM, deadalnix wrote:
I raised that in November 2014 already.
I remember the discussion.
To be honest I'm to a point were I'm starting withdrawing from these
conversation because I have no idea how to reach to you guys. I could write on
toilet paper before using it to the
No, the DIP doesn't handle several levels of indirection.
What about:
struct Bar { int a; int b }
auto rcs = RefCountedTree!(string,Bar)();
fcs["bar"].a = 1337; // log n
fcs["bar"].b = 1338; // log n
? I need to pay log n twice to assign two members
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
With conditionals, the scope of it is the narrowest scope of
each of its leaves.
(cond ? a : c) =// not ok, accepted even though a
outlives b
I had overlooked the lvalue case, but you're right. The rules
for it are
On Friday, 12 August 2016 at 09:42:35 UTC, Robert burner Schadek
wrote:
On Thursday, 11 August 2016 at 22:00:06 UTC, Walter Bright
wrote:
On 8/11/2016 4:46 AM, Robert burner Schadek wrote:
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
On Thursday, 11 August 2016 at 22:00:06 UTC, Walter Bright wrote:
On 8/11/2016 4:46 AM, Robert burner Schadek wrote:
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
No,
On Thursday, 11 August 2016 at 21:28:57 UTC, sclytrack wrote:
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it
On 8/11/2016 4:46 AM, Robert burner Schadek wrote:
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
No, because the lifetime of zero exceeds the lifetime of rcs[0].
On 8/11/2016 6:36 AM, Marc Schütz wrote:
1) `scope` on local variables is unnecessary. Requiring it probably makes the
implementation easier, but it doesn't need to be specified explicitly because it
can always be inferred.
Yes, it can be easily inferred from the initializer, and I plan to do
On 8/11/16 5:42 PM, sclytrack wrote:
On Thursday, 11 August 2016 at 21:28:57 UTC, sclytrack wrote:
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
[...]
There is confusion between what lifetime and visibility in the DIP.
(Well, I am confused)
[...]
What are those puppy dogs
On Thursday, 11 August 2016 at 21:28:57 UTC, sclytrack wrote:
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
[...]
There is confusion between what lifetime and visibility in the
DIP.
(Well, I am confused)
[...]
What are those puppy dogs doing there? I don't have a
On 8/11/2016 4:40 AM, Robert burner Schadek wrote:
Ok, I disagree, but there is no way that I can proof to be right. You can also
not proof that you're right, so I'll trust your judgement.
Thanks for the vote of confidence! I hope to justify it.
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it bypasses usual
nitpicking process and proceeds straight to
On 08/11/2016 11:07 AM, Jacob Carlborg wrote:
> On 10/08/16 22:36, Dicebot wrote:
>> http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
>>
>> The first DIP has just landed into the new queue. It is a proposal from
>> language authors and thus it bypasses usual nitpicking process and
On Thursday, 11 August 2016 at 13:36:06 UTC, Marc Schütz wrote:
2) The lifetime algebra contains lots of rules saying "only
applicable to pointer types". That's an indication that some of
the definitions weren't well chosen.
Yes, the spec should limit itself to types with and without
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
Proposal text:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
I trust the leadership that this is an important issue (including
for perception), but...
Does memory safety deserve such an extensive use of complexity?
My comments:
1) `scope` on local variables is unnecessary. Requiring it
probably makes the implementation easier, but it doesn't need to
be specified explicitly because it can always be inferred. It's a
tradeoff: do we want to make it easier for compiler writers to
implement, or do we want
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
with the DIP. I could find it.
Ok, I disagree, but there is no way that I can proof to be right.
You can also not proof that you're right, so I'll trust your
judgement.
On Thursday, 11 August 2016 at 09:45:07 UTC, Martin Nowak wrote:
It's already clear that we need much better escape analysis and
guards for safe reference counting.
There isn't any open question that this is the necessary
enabler for more RC and less GC.
How do you know? Is there a sketch for
On Thursday, 11 August 2016 at 08:29:37 UTC, John Colvin wrote:
lifetime(a) = all of foo
lifetime(c) = infinite (because null) //initially
lifetime(b) = lifetime() = lifetime(a) = all of foo //
lifetime(c) = lifetime() = lifetime(b) = all of foo //on
assignment in bar
That would suggest
On 8/11/2016 3:00 AM, deadalnix wrote:
This DIP is flawed because it only handle on
indirection level and break down for anything more than this.
It actually does two levels - the address of the pointer variable ('ref') and
the contents of the pointer variable ('scope'). But you are
On Thursday, 11 August 2016 at 08:29:37 UTC, John Colvin wrote:
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
Proposal text:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Can someone talk me through the lifetime algebra for the
following?
void foo()
{
int a;
On 8/11/2016 2:06 AM, Robert burner Schadek wrote:
The DIP should make clear that this is wanted for a container library.
Additionally, I miss how this DIP fits in the overall plan of getting rid of the
GC. As long as there isn't a written masterplan how to combine those ideas I
consider this
On Thursday, 11 August 2016 at 09:06:50 UTC, Robert burner
Schadek wrote:
The DIP should make clear that this is wanted for a container
library.
Additionally, I miss how this DIP fits in the overall plan of
getting rid of the GC. As long as there isn't a written
masterplan how to combine those
On 11/08/2016 9:06 PM, Robert burner Schadek wrote:
```
void foo() {
int c;
int* e;
e = // Error, lifetime(e's view) is and is greater than
lifetime(c)
}
```
The DIP should make clear that this is wanted for a container library.
Additionally, I miss how this DIP fits in
```
void foo() {
int c;
int* e;
e = // Error, lifetime(e's view) is and is
greater than lifetime(c)
}
```
The DIP should make clear that this is wanted for a container
library.
Additionally, I miss how this DIP fits in the overall plan of
getting rid of the GC. As
On Thursday, 11 August 2016 at 08:45:38 UTC, Walter Bright wrote:
On 8/11/2016 1:29 AM, John Colvin wrote:
Can someone talk me through the lifetime algebra for the
following?
void foo()
{
int a;
int** c;
void bar()
{
int* b = <= ok, b has a smaller lifetime than a
On 8/11/2016 1:29 AM, John Colvin wrote:
Can someone talk me through the lifetime algebra for the following?
void foo()
{
int a;
int** c;
void bar()
{
int* b = <= ok, b has a smaller lifetime than a
c = <= error, c has a larger lifetime than b
}
On Thursday, 11 August 2016 at 08:07:08 UTC, Jacob Carlborg wrote:
On 10/08/16 22:36, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
proposal from
language authors and thus it bypasses usual nitpicking
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
Proposal text:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Can someone talk me through the lifetime algebra for the
following?
void foo()
{
int a;
int** c;
void bar()
{
int* b =
c =
On 10/08/16 22:36, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it bypasses usual nitpicking process and
proceeds straight to requesting community (your!)
On 8/11/2016 12:13 AM, ZombineDev wrote:
What's current support in the master DMD branch for this DIP and what remains to
be done?
The current support has been stalled for 17 days now.
https://github.com/dlang/dmd/pull/5972
I know that some support was added in between the various @safe-ty
On Thursday, 11 August 2016 at 07:13:34 UTC, ZombineDev wrote:
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it bypasses usual
nitpicking process and proceeds straight to
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
- Please submit pull requests to adjust the markdown document
if you want to propose any improvements (mentioning
@WalterBright and @andralex for confirmation).
88 matches
Mail list logo
