• Steven Schveighoffer (13/26) May 04 2016 Sorry this didn't get asked, but here is the answer:
• Jack Stouffer (9/12) May 04 2016 Well, in most cases the length function should be marked const
• Steven Schveighoffer (13/24) May 04 2016 For front, I would use inout since it's an accessor, and for length I
• Vadim Goryunov (12/12) May 05 2016 Question to Liran Zvibel:
• Liran Zvibel (22/28) May 08 2016 Hi Vadim,

Steven Schveighoffer <schveiguy yahoo.com> writes:

(moved from the old 2015 thread)

On 5/4/16 5:44 PM, Jack Stouffer wrote:
 On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote:
 John Colvin's experiment is great and we want to make it a full
 success. Please post here feedback and suggestions for tomorrow's
 DConf streaming. Thanks! -- Andrei

 The chat for UStream is sporadic and mostly broken.

 I wanted to ask Steven a question and I don't have a twitter, so I
 wanted to use the integrated chat, but it had serious problems loading.
 Once it did load, when I posted something it would tell me my post
 failed to be sent.

 My question for Steve:

 "Can I use inout to make a length function for a range that is
 automatically const if the underlying data/range's length function is
 const? It would need to go all the way down for composed ranges."

Sorry this didn't get asked, but here is the answer:

No :)

The problem is that if the underlying range does not support const or 
inout, then when the type itself is inout, the subtype will be inout, so 
we cannot call functions that aren't marked properly. Remember when 
inside an inout function, you don't know what the unwrapped mutability 
modifier actually is.

Here is the problem however, ranges are pretty useless if they are not 
mutable. So this really isn't something that's super-important to solve. 
Do you have a specific use case?

-Steve

Jack Stouffer <jack jackstouffer.com> writes:

On Wednesday, 4 May 2016 at 17:23:01 UTC, Steven Schveighoffer 
wrote:
 So this really isn't something that's super-important to solve. 
 Do you have a specific use case?

 -Steve

Well, in most cases the length function should be marked const 
because it usually doesn't modify the struct in any way. But this 
isn't possible if you have a composed range because you don't 
know if the data/range underneath has a const length. This also 
applies to the front function in a lot of cases. And because of 
these two cases I think adding const to a lot of the member 
functions could result in slightly better code-gen.

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 5/4/16 7:32 PM, Jack Stouffer wrote:
 On Wednesday, 4 May 2016 at 17:23:01 UTC, Steven Schveighoffer wrote:
 So this really isn't something that's super-important to solve. Do you
 have a specific use case?

 -Steve

 Well, in most cases the length function should be marked const because
 it usually doesn't modify the struct in any way. But this isn't possible
 if you have a composed range because you don't know if the data/range
 underneath has a const length. This also applies to the front function
 in a lot of cases. And because of these two cases I think adding const
 to a lot of the member functions could result in slightly better code-gen.

For front, I would use inout since it's an accessor, and for length I 
would say const.

But there is no automated way "do the same thing" with attributes. 
People have proposed a const(true) or similar system so you can 
determine at compile time whether you should attach an attribute or not 
(and for other reasons). But other than that, the only way is to write 2 
versions of the function, one inout and one mutable, and only compile 
one based on the underlying function. It sucks, but I don't see another way.

Again, this is the viral thing. It's what makes it sooo difficult to use 
const or inout with generic functions. You have to *know*, or at least 
assume that all types you are working with will also be const correct.

-Steve

Vadim Goryunov <vadim.goryunov gmail.com> writes:

Question to Liran Zvibel:
Did you (Weka.IO team) consider possibility to write all code in 
zeroGC fashion? i.e. pre-allocating as much as possible, using 
manual malloc/free for regular allocations or using arena-style 
allocator for temporary stuff? If yes, why did you ended up in 
using GC.

I have experience writing in zeroGC style in Java. That means no 
new object is created during the working cycle: ok to create some 
garbage at the start-up or increase some storage arrays of 
primitive from time to time, but the target is - GC is not 
triggered during the day at all. My expectation is that writing 
in zeroGC style in D should be simpler.

Liran Zvibel <liran weka.io> writes:

On Thursday, 5 May 2016 at 21:51:56 UTC, Vadim Goryunov wrote:
 Question to Liran Zvibel:
 Did you (Weka.IO team) consider possibility to write all code 
 in zeroGC fashion? i.e. pre-allocating as much as possible, 
 using manual malloc/free for regular allocations or using 
 arena-style allocator for temporary stuff? If yes, why did you 
 ended up in using GC.

Hi Vadim,

Of course we allocate everything via pools (the style you 
describe as ZeroGC).

Our problem is that some features of D force the GC on you, and 
we have to work-around these cases.
For example -- Associative Arrays in D work through the GC so we 
have to come up with our own solution, exception handling in the 
runtime forces GC based allocation that we worked around to 
avoid, and many usecases of runtime scopes, such as delegations.

We have a lot of experience writing D code without the GC, but it 
does require paying attention, and not using the some of the 
"freebies" that come with D.

I agree with you, that using pooled resources for allocation is 
another example where D is much superior to Java.
I even illustrated a good example on my talk: the 
NetworkBufferPtr example of my talk showed how we leverage D to 
verify that the pointer we keep for a pooled-allocation 
NetworkBuffer always came from the right "generation" of that 
allocation, making the use much safer.

Cheers
Liran.