On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
> On 28.04.2017 23:52, H. S. Teoh via Digitalmars-d wrote:
>> On Fri, Apr 28, 2017 at 09:50:49PM +0000, Atila Neves via Digitalmars-d wrote:
>>> On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad wrote:
>>>> On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad wrote:
>>>> «Back in the old DOS days, there were multiple pointer types (near
>>>> and far). Programmers put up with that because it was the only way,
>>>> but they HATED HATED HATED it.»
>>>
>>> It's true, we did. It was awful.
>> [...]
>>
>> I remember working with that.  It was a royal PITA.
>>
>>
>> T
>>
>
> I don't doubt that, but the implicit generalization is "multiple pointer types are necessarily always a royal PITA".

The "implicit generalization" is your interpretation, though.

On Saturday, 29 April 2017 at 08:45:26 UTC, Moritz Maxeiner wrote:
> On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
>> I don't doubt that, but the implicit generalization is "multiple pointer types are necessarily always a royal PITA".
>
> The "implicit generalization" is your interpretation, though.

No, it was brought up in a thread as an argument against having multiple pointer types. The thread was not about near/far pointers or segmented memory models.

On Saturday, 29 April 2017 at 09:24:35 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 29 April 2017 at 08:45:26 UTC, Moritz Maxeiner wrote:
>> On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
>>> I don't doubt that, but the implicit generalization is "multiple pointer types are necessarily always a royal PITA".
>>
>> The "implicit generalization" is your interpretation, though.
>
> No, it was brought up in a thread as an argument against having multiple pointer types.

It was brought up in that thread as an example of multiple pointer types having (I assume unintended) negative consequences. That's not the same as implying that *all* occurrences of multiple pointer types *will* have such negative consequences; at most, it implies that you have to be very careful when designing them, so as to avoid such consequences (and this latter part is *my* interpretation).

> The thread was not about near/far pointers or segmented memory models.

I am aware; it was originally about the viability of automatic reference counting in D, and its potential benefits/drawbacks compared to garbage collection.

On Friday, 28 April 2017 at 19:49:35 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 28 April 2017 at 17:48:47 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
>>> I'm hoping to put all information in one place. Then when someone on Reddit or HN or here starts making claims about the GC, I can give them one link that shows all of their options.
>>
>> That's nice. Just get your hopes up for it having an effect.
>
> Typo, I meant "don't"... Sloppy of me. Documentation is nice, but:
>
> 1. People will complain that it isn't possible.
>
> 2. When possible people will complain that it isn't in the standard library.
>
> 3. When in "std" people will complain that not enough libraries use it.
>
> 4. When libraries use it people will complain that it doesn't work with older libs.
>
> 5. When older libs have been rewritten to support it they will complain that it is better in Rust and C++ and not compatible with Rust and C++.
>
> Anyway, my main point is that programmers coming from such languages will most certainly complain if it isn't in the standard library because of interoperability between libraries, but that is basically just the bottom of the hill that you have to climb to get to a level where people stop complaining.

Many invested in Rust and C++ will look for arguments to support staying with their language. I've come to the conclusion that the D community is mostly to blame for not making a good case to the other group that are open to D, but for technical reasons or simply personal preference don't like GC, that D is still an option. There's no excuse for not making it easy to evaluate one's options for GC-less programming if we support that style of programming.

On Saturday, 29 April 2017 at 10:54:02 UTC, bachmeier wrote:
> Many invested in Rust and C++ will look for arguments to support staying with their language. I've come to the conclusion that the D community is mostly to blame for not making a good case to the other group that are open to D, but for technical reasons or simply personal preference don't like GC, that D is still an option. There's no excuse for not making it easy to evaluate one's options for GC-less programming if we support that style of programming.

Of course. It is useful for D-users who are looking for alternatives to the GC if written for that group. Finding complete and up to date information is always the biggest challenge for newbies.

Just don't expect it to have an effect on reddit users...