On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> We could also not plan for many major releases, but at least move to D3 for some major TLC to the language that is held back to prevent breakage.

I've got a feeling that major problem with significant changes isn't social, but the technological infrastructure. You can only evolve a code-base so far, at some point it becomes more efficient to start over from scratch.

> I work occasionally with Swift, and they move very fast, and break a lot of stuff, but only in major versions. It's a bit fast for my taste, but it seems to work for them.

It works for them because of the app-market, and Swift is the only reasonable option next to Objective-C++ (and in some cases Dart).  Because Swift changes so much (and does not perform all that well), I am currently more inclined to use Objective-C++ for my own OS-X project.

I agree though that it helps with major versions, if the vendor is keeping the older versions alive as with Python 2. I am still running Python 2, an update is too costly, not worth it.

Same issue with Angular, they sometimes remove stuff for which there is a replacement, but it can still take a lot of time to make the transition.

Go1 and C++ on the other hand have very little breakage, even if they evolve.

> The biggest drawback is that we aren't a huge language, with lots of manpower to keep x branches going at once.

Actually, I think the biggest drawback is that you probably should start with a clean slate implementation if you intend to make major changes.

On Monday, 30 March 2020 at 01:14:06 UTC, Steven Schveighoffer wrote:
> On 3/29/20 9:02 PM, H. S. Teoh wrote:
>> [...]
>
> Good points, but I think that we are currently suffering from a different problem -- people want to, and do, implement these things, only to be told no, sorry we want it but we can't use it, because it breaks things. I listed several things that have been implemented but were rejected (or merged and reverted). Some of them even by the creator and BDFL of the language. Some other things are just wholesale changes to the library that implementing them is just not going to happen without some significant buy-in from the community and leaders.
>
> On top of that, people who may want to implement things are gun shy after seeing language changes get shot down left and right.
>
> Yes, we also still need leadership to approve and agree that X should be implemented. But right now, even they say X should be implemented, but we just can't without breaking "everything".
>
> What we need is a place for that answer to be yes instead. If not D3.0, I don't know what is the correct path for such things.
>
> -Steve

Hey, I'm still waiting for leadership feedback for _adding_ and not _changing_ a Phobos method: adding @nogc to socket receive!

What's the _policy_ in evolving _obsoleted_ modules? One year and an half of ... fog ...

:-P

The canary in the mine ... no pun intended!

On Monday, 30 March 2020 at 06:19:47 UTC, rikki cattermole wrote:

> There is no right answer.
>
> Whatever option you go with, you will have cases where you will want to cast to a more appropriate type.
>
> With the C promotion rules at least, most C family developers should be able to understand them and they will "just work" including when they are porting code from other languages.

Then let's not change anything at all - after all, someone will have to learn this changes too. :-)

On 3/30/20 1:54 AM, rikki cattermole wrote:
> On 30/03/2020 6:51 PM, Denis Feklushkin wrote:
>> On Sunday, 29 March 2020 at 13:34:44 UTC, Steven Schveighoffer wrote:
>>> On 3/28/20 1:09 PM, Denis Feklushkin wrote:
>>
>>>> int -> int32
>>>> ulong -> uint64
>>>> float -> float32
>>>> double -> float64
>>>> byte -> octet
>>>
>>> I would say no, for 2 reasons. One, this is basically renaming without benefit.
>>
>> My second proposal is remove auto casting to int while calculations:
>> int8 * int8 == int16 (not int32)
>>
>> Sometimes it causes unncessary casts. Intuitively it seems that it is uneconomical and possibly spoils superscalarity.
>>
>> Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)
> 
> C integer promotion is a feature, it is not going anywhere.

First, it's only a feature in that it means C code compiled as D will do the same thing as C (as long as it compiles). In other words, it's the C compatibility that's a feature, not that C integer promotion is the most desirable mechanism.

Second, it doesn't take long to break down:

auto z = x * y + 1000; // z must be int, no matter what type and y are.

The unnecessary casts are not terrible in any case, because at least you are aware of the odd truncation effect, I would say there's very little utility in the truncation effect.

A better option is to use more sane checked integer types if you want certain behavior.

-Steve

On 2020-03-30 07:51, Denis Feklushkin wrote:

> Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)

Yes, kind of. It was said if you copy-paste C code to a D file and it compiles, it should have the same behavior as in C.

-- 
/Jacob Carlborg

On Mon, Mar 30, 2020 at 07:09:30PM +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 2020-03-30 07:51, Denis Feklushkin wrote:
> 
> > Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)
> 
> Yes, kind of. It was said if you copy-paste C code to a D file and it compiles, it should have the same behavior as in C.
[...]

Isn't that still true?  Keyword here being, "if it compiles".


T

-- 
Philosophy: how to make a career out of daydreaming.

On Monday, March 30, 2020 11:30:45 AM MDT H. S. Teoh via Digitalmars-d wrote:
> On Mon, Mar 30, 2020 at 07:09:30PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
> > On 2020-03-30 07:51, Denis Feklushkin wrote:
> > > Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)
> >
> > Yes, kind of. It was said if you copy-paste C code to a D file and it compiles, it should have the same behavior as in C.
>
> [...]
>
> Isn't that still true?  Keyword here being, "if it compiles".

Mostly. IIRC, there are a few cases where it's not (e.g. a function parameter which is a static array in D will effectively compile as a dynamic one in C, because C only ever passes arrays as pointers), but in almost all cases, C code is either valid D code with the same semantics, or it doesn't compile.

- Jonathan M Davis

On 31/03/2020 12:02 AM, Paolo Invernizzi wrote:
> On Monday, 30 March 2020 at 01:14:06 UTC, Steven Schveighoffer wrote:
>> On 3/29/20 9:02 PM, H. S. Teoh wrote:
>>> [...]
>>
>> Good points, but I think that we are currently suffering from a different problem -- people want to, and do, implement these things, only to be told no, sorry we want it but we can't use it, because it breaks things. I listed several things that have been implemented but were rejected (or merged and reverted). Some of them even by the creator and BDFL of the language. Some other things are just wholesale changes to the library that implementing them is just not going to happen without some significant buy-in from the community and leaders.
>>
>> On top of that, people who may want to implement things are gun shy after seeing language changes get shot down left and right.
>>
>> Yes, we also still need leadership to approve and agree that X should be implemented. But right now, even they say X should be implemented, but we just can't without breaking "everything".
>>
>> What we need is a place for that answer to be yes instead. If not D3.0, I don't know what is the correct path for such things.
>>
>> -Steve
> 
> Hey, I'm still waiting for leadership feedback for _adding_ and not _changing_ a Phobos method: adding @nogc to socket receive!
> 
> What's the _policy_ in evolving _obsoleted_ modules? One year and an half of ... fog ...
> 
> :-P
> 
> The canary in the mine ... no pun intended!

std.socket is not obsolete.

But in this case receive can be @nogc if the internals allow it to be.

It does not take callbacks, or anything like that.

The only issue surrounding this is if somebody has decided to inherit from one of the socket classes. Which is kinda a bad thing to do regardless...

So ask point blank if anybody has done it, and it should be fine.

On Monday, 30 March 2020 at 21:24:31 UTC, rikki cattermole wrote:
> But in this case receive can be @nogc if the internals allow it to be.

it can, this should be a trivial change.

> The only issue surrounding this is if somebody has decided to inherit from one of the socket classes. Which is kinda a bad thing to do regardless...

It is a useful thing to do - I did for SSL support, for example. But my ssl socket child class is also nogc compliant, as I suspect most people's would be.

On Mon, Mar 30, 2020 at 09:28:44PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Monday, 30 March 2020 at 21:24:31 UTC, rikki cattermole wrote:
> > But in this case receive can be @nogc if the internals allow it to be.
> 
> it can, this should be a trivial change.
[...]

In the name of getting stuff done instead of just talking about it:

	https://github.com/dlang/phobos/pull/7433


[...]
> > The only issue surrounding this is if somebody has decided to inherit from one of the socket classes. Which is kinda a bad thing to do regardless...
> 
> It is a useful thing to do - I did for SSL support, for example. But my ssl socket child class is also nogc compliant, as I suspect most people's would be.

Hmm.  Wouldn't this be a problem if changing .receive to @nogc break existing code that inherits from Socket?


T

-- 
Let's call it an accidental feature. -- Larry Wall