On 11/08/2016 5:41 PM, Walter Bright wrote:
On 8/10/2016 10:05 PM, rikki cattermole wrote:
Question:
I see RefCountedSlice example, does this mean if I alias this say like:
struct FooBar;
struct Foo {
FooBar* v;
scope FooBar* get() { return v; }
alias this get;
}
That it will ope
On 8/10/2016 10:05 PM, rikki cattermole wrote:
Question:
I see RefCountedSlice example, does this mean if I alias this say like:
struct FooBar;
struct Foo {
FooBar* v;
scope FooBar* get() { return v; }
alias this get;
}
That it will operate correctly in the below case?
func(myFoo
This bit seems odd:
T func(T* t) {
return t; // ok
}
Is there an implicit conversion from T* to T?
On Wed, Aug 10, 2016 at 10:05 PM, rikki cattermole via
Digitalmars-d-announce wrote:
> On 11/08/2016 8:35 AM, Dicebot wrote:
>
>> The first DIP has just landed into the new queue. It is a prop
On 11/08/2016 8:35 AM, Dicebot wrote:
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!) feedback.
Essentially, it is an attempt to solve reference lifetime p
On 8/10/2016 4:56 PM, Nicholas Wilson wrote:
How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant]
interact with LDC's GC to stack promotion pass?
I don't know about how that works in LDC, but general such a promotion can only
be done if the compiler can prove there are no
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
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!) feedback.
[...]
How will the infinite lif
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!) feedback.
Essentially, it is an attempt to solve reference lifetime problem
by extending implementation
On Wednesday, 10 August 2016 at 18:35:03 UTC, Sebastiaan Koppe
wrote:
Yes, but from past experience we know that people don't look
at results, if you don't make it part of PR acceptance.
So true. Then I will do PR's first.
Thinking about it, you could also opt for integrating it with the
dmd
On Wednesday, 10 August 2016 at 10:32:24 UTC, Martin Nowak wrote:
We want better ranking of dub packages (mostly by download, but
for sure also showing CI results [ยน]).
I was also thinking about integrating results from CI builds that
packages do themselves. But there is some 'impedance mismat
On 08/10/2016 01:12 PM, Steven Schveighoffer wrote:
On 8/1/16 10:11 AM, Steven Schveighoffer wrote:
I posted this a while ago, forgot to announce. Please join us if you are
in the area! Already 5 going.
http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/232865668/
Another
On 8/1/16 10:11 AM, Steven Schveighoffer wrote:
I posted this a while ago, forgot to announce. Please join us if you are
in the area! Already 5 going.
http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/232865668/
Another ping. Happening tomorrow!
-Steve
On Tuesday, 9 August 2016 at 15:37:27 UTC, Martin Nowak wrote:
Please report any bugs at https://issues.dlang.org
I'd appreciate it if someone could have a look at this regression:
https://issues.dlang.org/show_bug.cgi?id=16369
On 08/09/2016 09:43 AM, celavek wrote:
> If anyone has ideas for new exercises please contribute or if the time
> is an issue send me
> a message with a clear problem statement and a set of unit tests.
>
> I would like to say that for me the sit worked quite well and it helped
> me get started
> w
On 08/08/2016 09:54 AM, Sebastiaan Koppe wrote:
> On Sunday, 7 August 2016 at 23:08:34 UTC, Martin Nowak wrote:
>> I actually don't think this makes sense. You're not in the position to
>> maintain 1K+ packages, it's the library owners that need to test their
>> code.
> Thanks for taking the time t
14 matches
Mail list logo