November 04, 2018
On Saturday, 3 November 2018 at 03:58:16 UTC, Ali Çehreli wrote:
> On 11/02/2018 03:18 AM, ShadoLight wrote:
>
> > Maybe you are thinking of the "Prefer non-member non-friend
> functions to
> > member functions" rule from Herb Sutter's "Effective C++"
> books?
>
> Scott Meyers.
>
> Ali

<Facepalm!> Thanks for the correction.
November 04, 2018
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
> On Sun, 04 Nov 2018 11:36:39 +0000, FooledDonor wrote:
>> Can we argue about the problems arising from the potential introduction of this feature?
>
> There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain.
No one should/need learn the entire tool itself in order to get thing done. If you found yourself in such a situation, then you seriously need to rethink on what you should be doing.

-Alex
November 05, 2018
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
>
> There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain.
>
> So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things.
>
> The justification for this feature rests on real-world examples of bugs that have been caused by its lack.

You keep turning this argument around, as though it is a request to change D.

We should be able to have a discussion, about ways to further improve type safety inside a module, without being constantly taunted by your hyperbole.

The discussion might even lead to ways to help programmers address the issues being raised, that don't require a change to D (and I don't mean 'just put your class/struct in it's own module').

Now, the fact is, that the D module is a conglomeration of different types.

None of the types declared within a module has any independence from any other type, within the module. Fact.

Some clearly think this is a good thing. Fine, you have it that way already. That will never change.

But some think this requires an undue burden on the part of the programmer to be extra vigiliant around how they compose their types. Sure a few lines in module, you can easily do that. But as the number of line increase, so would the chances of you doing something you never intended to do. There is no way the programmer to provide a guarantee around the use of a type, from other code in the module, since the data and methods in any type are mutable from outside that type.

Some think this shared mutability between types within a module, can lead to bugs and unsafe behaviour.

Some think it might be nice, if the programmer had a means to provide better guarantees for the their declared types.

Type safety is an important and critical component in software architecture.

It's not something you should 'agressively filter out' from discussion.

Whether the language could handle a change to address this, would be a further stage of the discussion. From what I hear, it may not be able to handle such a change, and the D module is doomed to be what it is, and programmers will bear the responsibilty for type safety within a module.

November 05, 2018
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
>
> There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain.
>
> So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things.
>
> The justification for this feature rests on real-world examples of bugs that have been caused by its lack.

I think there are more than enough real-world examples, of where issues around 'type safety', or lack of, have caused a sufficient number of bugs, to warrant a discussion about ways to further improve type safety.

D module's are not type safe, at least as far as the code within that module is concerned. To have to go to silly lengths just to get type safety in D.

D is language the favors convenience 1st. type safety 2nd... or is it 3rd..

This lack of enforcable type safety *within* a module, leads to undisciplned code. Phobos is a 'real-world' example of it.

D needs an 'Industrial Strength D' book, as well as an 'Effective D'.

I assume the moderator(s) doesn't like me anymore, as my posts are no longer being published. Great way to run a discussion forum by the way.



November 05, 2018
On Monday, 5 November 2018 at 01:23:44 UTC, nobodycares wrote:

> I assume the moderator(s) doesn't like me anymore, as my posts are no longer being published. Great way to run a discussion forum by the way.

It not just you, my post had disappear only to reappear on later dates. I can vouch for them by saying that this is a bug that you and I are experiencing.

-Alex
November 05, 2018
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote:
> On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
>> When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake.  It might be better to suspend judgement for a while and keep an open mind.
>
> So true. My ideas on how to write code have changed dramatically over the years, and continue to change.

I hear the advantages of the way D does it.

But nobody wants to hear about the disadvantages.

Am I the only one who needs to keep an 'open mind'?

What harm can come, from an optional tool, that enables enforceable encapsulation of a type, within a module (from code also in the module, but outside that type)?

Can someone please answer that?

And yet again, I remind people that this is not a request for change. This is a discussion about what benefit such a tool can bring.
November 05, 2018
On Mon, 05 Nov 2018 01:23:44 +0000, nobodycares wrote:
> I think there are more than enough real-world examples, of where issues around 'type safety', or lack of, have caused a sufficient number of bugs, to warrant a discussion about ways to further improve type safety.

You do realize we can all see that you're posting from the same IP address with three different usernames, don't you? How's the dual boot working out? Firefox 52 is kind of old; are you holding off on updating for addon compatibility?

If you want to make a good sockpuppet, you'll need to invest some effort. Different browsers for each. Different IP addresses. Usernames that look like reasonable human names or forum handles. Posting about topics other than your personal cause.

And if you had actual examples, you'd have shown them already.
November 05, 2018
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote:
> On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
>> When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake.  It might be better to suspend judgement for a while and keep an open mind.
>
> So true. My ideas on how to write code have changed dramatically over the years, and continue to change.

what are your thoughts on implicit conversions, given your obvious experience?

To me, implicit conversion are code smells, as they undermine the independence of types (and as you've probably gathered, I very much like type independence..a lot).

Did you do it this way for C like compatability?

Would you do it differently, if you could?

uint x = -10; // what!

int x;
bool y = true;
x = y; // what!

etc..

November 05, 2018
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov wrote:
>
> The only difference is that `func` became a member function. And now what? You can just as easily "forget" what's in your struct/class as in your whole module.

ok. Now, what are your options then (assuming you want an independent type)?

(option 1) define one encapsulated type, per module.
(option 2) have a means for type independence within a module - i.e. selective hiding.

D only gives you one choice here, not two.

I would say, that your response backs up my argument, that is, a second option might actually be worthwhile. perhaps, something like: __private

(now __private is everything private already is, but additionally, its private outside the scope of the type declaring it, and now, you'd get a compile time guarantee of correctness - e.g. if you accidently tried to ignore that types independence.

It's call 'type encapsulation' ;-)

November 05, 2018
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity wrote:
> ok. Now, what are your options then (assuming you want an independent type)?
>
> (option 1) define one encapsulated type, per module.
> (option 2) have a means for type independence within a module - i.e. selective hiding.
>
> D only gives you one choice here, not two.

Is having two choices really better than having one choice?

When you only have one choice, you don't have to make any decisions. When you have two choices, you are *forced* to make a decision, whether you want to or not.

That can be a good thing, when the decision you're making is meaningful--for example, when you're deciding whether to use GC or manual memory management. But when the decision you're making is meaningless--for example, when you're deciding whether to indent with tabs or spaces--it's just a waste of time. It doesn't matter which you choose, but you're forced to make a decision anyway. (Or, even worse, your entire team is forced to waste time *agreeing* on a decision together.)

When it comes to encapsulation, it makes no *functional* difference whether you achieve it by putting all your types into separate modules, or by using something like `__private`. The end result is the same either way. The only reason to prefer one over the other is personal taste--in other words, it's a matter of style, just like tabs vs. spaces.

Personally, I don't think there's anything wrong with preferring `__private` over separate modules, just like I don't think there's anything wrong with preferring spaces over tabs. But I think being forced to make meaningless decisions is bad no matter what you prefer, and because of that, I don't think `__private` should be added to D.