June 16, 2022

On Thursday, 16 June 2022 at 13:15:52 UTC, bauss wrote:

>

On Thursday, 16 June 2022 at 13:02:11 UTC, Chris Katko wrote:

>

On Thursday, 16 June 2022 at 12:08:27 UTC, Ola Fosheim Grøstad wrote:

>

If you can detect it, then it is a breaking change in the context of meta-programming.

Isn't that like saying: adding a uint128 type breaks the language. Because you can detect it?

It is and I think it's far from a solid argument against anything.

Actually, on second thoughts, it would not be a breaking change as it is listed in the language spec:

https://dlang.org/spec/type.html

I guess one could say that the compilers are not compliant, unless I missed a footnote somewhere.

Basically, whether it is a breaking change or not, depends on the wording of the language spec (if you have one). If it says that you should not assume this or that, then it is not a breaking change even if people do assume this or that (because the code they wrote was outside the spec and could be considered undefined behaviour).

June 16, 2022
On Thursday, 16 June 2022 at 09:04:25 UTC, bauss wrote:
> On Thursday, 16 June 2022 at 09:01:56 UTC, Basile B. wrote:
>>
>> I volonteer but be warned I'll propose to introduce "super private".
>
> No that is ambiguous because it sounds like it's private to the super class.
>
> It absolutely cannot use the super keyword.

meh in this context "super" would mean "really really"
June 16, 2022
On Thursday, 16 June 2022 at 14:58:33 UTC, Basile B. wrote:
> On Thursday, 16 June 2022 at 09:04:25 UTC, bauss wrote:
>> On Thursday, 16 June 2022 at 09:01:56 UTC, Basile B. wrote:
>>>
>>> I volonteer but be warned I'll propose to introduce "super private".
>>
>> No that is ambiguous because it sounds like it's private to the super class.
>>
>> It absolutely cannot use the super keyword.
>
> meh in this context "super" would mean "really really"

extra private!
megapint private!
"classified"
exclusive
secret
June 16, 2022
On Thursday, 16 June 2022 at 11:45:11 UTC, Olivier Pisano wrote:
>
> ..
> I am suggesting you write a DIP, so you can come with an evaluation of this cost, since you are the one asking for it.

To be honest, any DIP that only has one name written on it, is a red flag to me.

The point of discussing this first, is not replace the DIP process, but to enhance the quality of it, so it can be considered on merits, and not all the silly arguments that always arise when scope privacy is raised.

So far, it seems like all the silly arguments have been exhausted ;-)

But wow... it took a while.
June 16, 2022
On Thursday, 16 June 2022 at 11:10:33 UTC, Kagamin wrote:
>
> ...
> When you have a lazily initialized field, you need to use an accessor, because if you read the raw field, you get an uninitialized value and error as a result, so only the accessor should have access to the field.

I think the answer here, is that if you can't access a lazily initialized field because you made it 'private(scope)', then don't make it 'private(scope)'.

'private(scope)' is not meant to replace anything.

'private(scope)' would just be a design constraint 'option' (an option that so many of us have had for decades), for you to use when you think it is appropriate for you to use. You explicately state your intent with it, and the compiler will know and enforce that intent (at compile time).

June 17, 2022
On Thursday, 16 June 2022 at 23:02:05 UTC, forkit wrote:
> On Thursday, 16 June 2022 at 11:45:11 UTC, Olivier Pisano wrote:
>>
>> ..
>> I am suggesting you write a DIP, so you can come with an evaluation of this cost, since you are the one asking for it.
>
> To be honest, any DIP that only has one name written on it, is a red flag to me.

common, just common.

The DIP process is good. What would you think of a democracy where decisions are took every time someone gets angry. Doors open to lobbying.
lobbying leads to completly incoherant communities that are actually shaped of sub-communities that barely tolerate themselves.

Passed the elipse, what I mean is that "you cant always get what you want", just like in real life you have to accept that the way of living is an unperfect compromise between people. So is a programming language that's actually used IRL.

The way to bring changes is not anger, it's called DIP.


June 17, 2022
On Friday, 17 June 2022 at 01:09:29 UTC, Basile B. wrote:
>
> ..
> The way to bring changes is not anger, it's called DIP.

yes I agree.

btw. I cannot recall every gettng angry over this issue ;-)

frustrated yes, angry no.

In any case. I've made two decisions.

(1) Not to proceed with this idea
(2) To stop using D, completely.

Reasons for (1) are that the vast majority of D users do not compose problems using OO like decomposition. So it is almost impossible to find like minded people willing to co-author a DIP like this. Also, since most D users do not do OO decomposition, it would be difficult to find support for the DIP once introduced.
Also, Walter would certainly prevent it, regardless.

Reasons for (2). This comes back to Walter waking up one morning and putting ImportC into the langauge at his own volition, and nobody really challenging that.
That makes me nervous. It means anything could happen anytime in D, if Walter makes that decision. I felt really uncomfortable using D ever since I say the 'trivial' PR from Walter!

I'm moving on.

So you're welcome to let this thread die off.

Alternatively, I'm sure Mike is eager to find a reason to lock it - now he has one ;-)


June 17, 2022
On Thursday, 16 June 2022 at 23:02:05 UTC, forkit wrote:
> On Thursday, 16 June 2022 at 11:45:11 UTC, Olivier Pisano wrote:
>>
>> ..
>> I am suggesting you write a DIP, so you can come with an evaluation of this cost, since you are the one asking for it.
>
> To be honest, any DIP that only has one name written on it, is a red flag to me.
>
> The point of discussing this first, is not replace the DIP process, but to enhance the quality of it, so it can be considered on merits, and not all the silly arguments that always arise when scope privacy is raised.

The point of the DIP process is to enhance the proposal. Almost every DIP starts as a result of forum discussions. All the discussion you've done so far, for example, surely has provided enough material for an initial draft. When you're drafting the DIP, you can come to the forums, give a link to the draft in your DIP repository fork, and discuss the topic further refine your arguments, take suggestions, etc.

Once you submit the draft, the DIP is in Draft Review while it's in the PR queue. People can come in and leave comments, and you can discuss and debate the proposal to improve it. The Community Review round(s) then serve to further refine it. The Final Review is one last chance to look for major flaws, then it's sent off to Walter and Atila for assessment.

Multiple people contribute to every DIP, no matter how many people actually have their name in the author field.


June 17, 2022
On Friday, 17 June 2022 at 01:09:29 UTC, Basile B. wrote:
> On Thursday, 16 June 2022 at 23:02:05 UTC, forkit wrote:
>> [...]
>
> common, just common.
>
> The DIP process is good. What would you think of a democracy where decisions are took every time someone gets angry. Doors open to lobbying.
> lobbying leads to completly incoherant communities that are actually shaped of sub-communities that barely tolerate themselves.
>
> Passed the elipse, what I mean is that "you cant always get what you want", just like in real life you have to accept that the way of living is an unperfect compromise between people. So is a programming language that's actually used IRL.
>
> The way to bring changes is not anger, it's called DIP.

Where is the DIP for ImportC or @live?
June 17, 2022

On Friday, 17 June 2022 at 06:18:30 UTC, Paulo Pinto wrote:

>

On Friday, 17 June 2022 at 01:09:29 UTC, Basile B. wrote:

>

On Thursday, 16 June 2022 at 23:02:05 UTC, forkit wrote:

>

[...]

common, just common.

The DIP process is good. What would you think of a democracy where decisions are took every time someone gets angry. Doors open to lobbying.
lobbying leads to completly incoherant communities that are actually shaped of sub-communities that barely tolerate themselves.

Passed the elipse, what I mean is that "you cant always get what you want", just like in real life you have to accept that the way of living is an unperfect compromise between people. So is a programming language that's actually used IRL.

The way to bring changes is not anger, it's called DIP.

Where is the DIP for ImportC or @live?

Atleast for @live, the closest thing to a formal document was DIP 1021, I believe

https://github.com/dlang/DIPs/blob/793f83911fdc8c88c6ef34e6a36b5e11e3e574e5/DIPs/DIP1021.md