RFC: scope and borrowing

[Manu via Digitalmars-d]

On 23 September 2014 19:45, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 9/22/2014 4:20 AM, Manu via Digitalmars-d wrote:
>>
>> On 22 September 2014 13:19, Walter Bright via Digitalmars-d
>> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>>
>>     On 9/21/2014 4:27 AM, Manu via Digitalmars-d wrote:
>>
>>         It's also extremely hard to unittest; explodes the number of static if paths
>>         exponentially. I'm constantly finding bugs appear a year after writing
>>         some code
>>         because I missed some static branch paths when originally authoring.
>>
>>
>>     If you throw -cov while running unittests, it'll give you a report on which
>>     code was executed and which wasn't. Very simple and useful.
>>
>>
>> It is a useful tool, but you can see how going to great lengths to write this
>> explosion of paths is a massive pain in the first place, let alone additional
>> overhead to comprehensively test that it works... it should never have been a
>> problem to start with.
>
>
> There are two separate issues here - the first is knowing whether or not the code is unittested. -cov solves that issue. The second is having the multiple code paths in the first place.
>
> Have you tried auto ref?

auto ref has never been what I've wanted. Semantically, it makes ref
out of all value-type lvalues, including int/float.
I don't want the compiler attempting to presume what I want in my
generic code. If it's part of the type, then there are no surprises;
it is exactly what I give it, which I gave deliberately.


> I don't really know what the code you show is supposed to do from a high level. My first impression is you are trying to write it like you'd write C++ code. Perhaps there's a more D idiomatic way of doing it that doesn't lead to the tangle you've got.

The only way I can think to eliminate that is to write the lot in a
huge mixin which composes the text from bits. I avoid mixin.

D has extensive language to manipulate and compare types, it has very
little to deal with these few weird external concepts like 'storage
class'. D has the most powerful type system I'm aware of, I see no
reason to break from that.
I think 'storage class' is a source of extreme complexity in D, since
it breaks uniformity with the rest of the language.


> BTW, ref (as you know) is part of the type in C++. However, I can vouch for it being a special case everywhere in C++, and is a horrifying quagmire of strange edge cases. That's why it's not part of the type in D.

I've never had any problems with ref in C++. D presents the horrible
quagmire of edge cases in my experience, some of which I've presented,
but I've had many more issues in the past.
Can you give me some examples of the problems in C++ you set out to
avoid? I've been programming C++ for 20 years, and D for 5-6 years.
I've never had this problem in C++, I have it so often in D, it drives
me crazy.

I also believe that D wouldn't suffer the same problems as C++,
because we have much better type manipulation. Things like
PointerTarget!T, Unqual!T, and all the other complex type manipulation
templates are common and work well in D, but that sort of thing almost
never works well in C++. The type comparison logic in C++ is too
feeble to be comparably useful.