On Friday, 2 November 2018 at 12:00:05 UTC, Atila Neves wrote:
> On Thursday, 1 November 2018 at 18:46:37 UTC, Patrick Schluter wrote:
>> On Thursday, 1 November 2018 at 14:28:27 UTC, Atila Neves wrote:
>>> On Tuesday, 30 October 2018 at 08:18:57 UTC, Bastiaan Veelo wrote:
>>>> On Tuesday, 30 October 2018 at 00:01:18 UTC, unprotected-entity wrote:
>>>>> On Monday, 29 October 2018 at 22:24:22 UTC, Bastiaan Veelo wrote:
>
>>> Friends don't let friends use unsigned types for counting.
>>
>> My experience is exactly the opposite. I inherited a code base of ~200K lines of C written over 3 decades by several developers of varying skills. You can not imagine how many bugs I found thanks to replacing int and long by size_t and uint32_t/uint64_t.
>>
>> int i = 0;
>> ints[--i];  // look ma, no errors or warnings! indeed
>>
>> with size_t i at least you get segfault or a bus error.
>
> I'm interested in knowing how you don't get a segfault with a signed integer. I'm guessing a big block of pre-allocated memory?

We were talking C here. An array access to offset -1 only goes to the memory befor the array. If the array is on the stack it's another variable or the return address of the function. It it's in the heap, it's generally some overhead structure of the allocator or another buffer if the chunk of memory is from a slab allocator. Only when using tools like efence or valgrind that will allocate a memory page for every allocated block will it be possible to crash with a a[-1] access.

>
>> The worst offense is using int on 64 bit machines when working on big datasets, overflows are really more common than people expect.
>
> The problem there is using `int`, not the fact that `int` is signed.

True. Only 2 billion happens before 4 billion.

>
>> When using unsigned, it requires indeed to be careful when interacting with other variable, but since when is sloppiness a virtue?
>
> In programming? Laziness is always a virtue. If I wanted to be careful when I write code, I wouldn't be on this forum.

I didn't say laziness (pereza), but sloppiness (descuidado) it's not the same thing.

>
> Besides, even if *I'm* careful, my colleagues might not be, and it'll be me paying the gdb price.
>
>> The thing is, all the code that used int as a default was code that was not thought through concerning the range of values and limits of the used variables.
>
> I learned C using 16-bit Borland, which meant `int` was the same as `short`. Every time I wrote a for loop back then I had to consider if I needed `long` instead.

Yeah, 16 bit Borland C was the horror if you had to work on far and huge memory model. The fun part was that size_t wouldn't have helped as it was only a unsigned int (if ever people wanted an example of a platform where sizeof(size_t ) < sizeof(long) real mode x86 is it).

On Friday, 2 November 2018 at 15:18:05 UTC, Q. F. Schroll wrote:
>
> How about public and private unittest?
>
> ...A private ...unittest, on the other hand, tests private state....

The problem is, that there is NO private state within a module.

Not even for struct.

Zilch! nəTHiNG!

Now, how many who want private state for their struct type, are going to go down the path of putting 'one struct per module'. But those of us who want it for a class, are told to do just that.

If only the programmer had a tool to define accessibility for a type, that would apply to accessibilty not just for code outside the module, but also to code within the module (but outside of that declared type), then:

-------------
class Test
{
    __private int Value;
}

unittest
{
    T t = new T();

    t.Value++; // No. it's private - so not accessible outside of the module.
               // No. it's also __private - so not accessible outside the type
}

------------

Anyone who argues that this syntax would make the language too complex, and therefore we should avoid any further discussion, cannot be take seriously.

On the otherhand, whether the actual implementation of such a feature, is doable, and workable with the language as a whole, I wouldn't know - and that is worth a discussion.

On Friday, 2 November 2018 at 12:53:44 UTC, Stanislav Blinov wrote:
> On Friday, 2 November 2018 at 11:43:13 UTC, Atila Neves wrote:
>> On Thursday, 1 November 2018 at 17:59:35 UTC, Steven Schveighoffer wrote:
>
>>> So... don't test private functions?
>>
>> Precisely.
>>
>> Caveat: test them if you *really* want to, but be prepared to delete the tests with extreme prejudice.
>>
>> I never do, implementation details are just that.
>
> Sometimes you need to, even if you don't want to. Say you're implementing a container, for simplicity let's say an Array!T (akin to Vector from your automem library). Because it's D, the author needs to be aware of GC implications. Namely, when removing elements from the array, or reserving additional storage, and `T` may have indirections, the Array should wipe unused storage (or appropriate bits) to eliminate false pointers. This isn't a part of public interface at all, but still something that should be tested against.

This is more a comment on the lack of druntime's lack of testability than anything else. I'm still annoyed (and slightly worried) that I can't test that I'm telling the GC what I'm supposed to.

On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
>
> I can't speak for others, but it's a feature I use fairly often. I tend to design aggregates and free functions to the module, as a cohesive whole, rather than as separate parts. If I want separate parts, I put them in different modules and use `package` for the bits that need to stay out of the public API. Works a treat.

+1
I also see how it could be a problem in a team.
There is a tension between features for a team with "shared ownership of code" and features for individual developers.

Perhaps there is way to do a "Voldemort member", something that can't be named outside of the class.