DConf2016 Livestream questions

[Steven Schveighoffer via Digitalmars-d]

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