On Monday, 30 March 2020 at 22:34:32 UTC, H. S. Teoh wrote:
> Hmm.  Wouldn't this be a problem if changing .receive to @nogc break existing code that inherits from Socket?

It technically breaks but it is a trivial fix, I'd be generally OK telling people to deal with it. But if someone has a case where it isn't trivial, well, we'd have to see why.

Some D classes in the past have done it by adding a new method with _nothrow or _nogc or whatever then deprecating the old. Or you could make a new subclass that tightens it there. There's various solutions but I don't think we even really need to worry - in practice it is all @nogc anyway at least in my experience.

On 3/30/20 6:46 PM, Adam D. Ruppe wrote:
> On Monday, 30 March 2020 at 22:34:32 UTC, H. S. Teoh wrote:
>> Hmm.  Wouldn't this be a problem if changing .receive to @nogc break existing code that inherits from Socket?
> 
> It technically breaks but it is a trivial fix, I'd be generally OK telling people to deal with it. But if someone has a case where it isn't trivial, well, we'd have to see why.

I could see an example of a SSL socket that allocates a buffer for processing the SSL on the first call to receive. Or it needs to extend an existing buffer to read more data.

-Steve

On Monday, 30 March 2020 at 22:34:32 UTC, H. S. Teoh wrote:
> 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


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

Please read the history and how it ended, that's the reason I'm citing that in that discussions ...

Citing Steven some message above:

"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_____."

Emphasis on "leaders" mine ..

On Sun, 2020-03-29 at 12:16 -0700, Walter Bright via Digitalmars-d wrote:
> 
[…]
> D's development path simply doesn't fit into the semantic versioning
> system.
> It's one of continuous change, not long periods of stability
> punctuated by
> wrenching change.

I think your understanding/appreciation of how semantic versioning works for a dynamic/agile project is failing you. Semantic versioning is entirely applicable to the DMD project – even if it is never going to happen.

> > 
[…]
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tuesday, 31 March 2020 at 12:57:04 UTC, Russel Winder wrote:
> On Sun, 2020-03-29 at 12:16 -0700, Walter Bright via Digitalmars-d wrote:
>> 
> […]
>> D's development path simply doesn't fit into the semantic versioning
>> system.
>> It's one of continuous change, not long periods of stability
>> punctuated by
>> wrenching change.
>
> I think your understanding/appreciation of how semantic versioning works for a dynamic/agile project is failing you. Semantic versioning is entirely applicable to the DMD project – even if it is never going to happen.
>
>> > 
> […]

Almost every release would be a major release or a patch release. Hard to see how it adds much value to follow Semantic Versioning in that case.

On Tuesday, 31 March 2020 at 17:00:28 UTC, John Colvin wrote:
> Almost every release would be a major release or a patch release. Hard to see how it adds much value to follow Semantic Versioning in that case.

Well, it might concentrate everyone's minds a bit if we had such a clear indicator of either breaking change or zero new features with every compiler release ... :-)

BTW, _why_ is there such a regular rate of breaking change?  Is it deliberate or accidental?  Assuming deliberate, why so regular?

On Tuesday, 31 March 2020 at 17:00:28 UTC, John Colvin wrote:
> On Tuesday, 31 March 2020 at 12:57:04 UTC, Russel Winder wrote:
>> On Sun, 2020-03-29 at 12:16 -0700, Walter Bright via Digitalmars-d wrote:
>>> 
>> […]
>>> D's development path simply doesn't fit into the semantic versioning
>>> system.
>>> It's one of continuous change, not long periods of stability
>>> punctuated by
>>> wrenching change.
>>
>> I think your understanding/appreciation of how semantic versioning works for a dynamic/agile project is failing you. Semantic versioning is entirely applicable to the DMD project – even if it is never going to happen.
>>
>>> > 
>> […]
>
> Almost every release would be a major release or a patch release. Hard to see how it adds much value to follow Semantic Versioning in that case.

Why do you think it would ? At the moment we have a sliding window for deprecation. We'd just change that to have a specific time for removal. I don't see how that would make every release a breaking change ?

On 2020-03-31 14:57, Russel Winder wrote:

> Semantic versioning is entirely applicable to the DMD project – even if it is never going
> to happen. 

How would that work? There are several components, would they all share the same version or have their own? I'm thinking of the following:

* The D language itself
* The ABI of the language
* The compiler, i.e. the CLI interface
* The DMD Dub package, i.e. the compiler as a library
* Phobos
* druntime

Additional components that are bundled with DMD in the release packages:

* ddmangle
* dub
* dumpobj
* dustmite
* obj2asm
* rdmd
* shell

-- 
/Jacob Carlborg

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.

I don't think heavy-handed breaking of backwards compatibility is worth it. Even if we were to do it, redesigning the standard library should be enough - no need to break the compiler.

>
> Some issues I can think of:
>
> 1. The safe by default debate
Isn't it quite simple? Just add a way to apply `@safe:` and `@system:` on the top of module without them applying to template inference, and it really does not matter what the default will be.

> 2. pure by default
> 3. nothrow by default
Same as above, except they obviously will need antiattributes that turn them off

> 4. String interpolation DIP
Should hardly be a breaking change

> 5. auto-decoding
This is the only thing of these that I think would make the transition worthwhile, were there many more issues of this caliber. But even this is only about Phobos, not the language spec.

> 6. range.save
Each range should just decide their behaviour on copy. Since forgetting to `.save` is so common, changing copy behaviour of a public range will break code anyway, so the behaviour can be guaranteed just as well.

> 7. virtual by default
Small issue after all. Can be further mitigated by adding `virtual` keyword so one can add `final:` on top and cancel it where applicable.

> 8. ProtoObject
No opinions on this - haven't followed.


That all being said, I would welcome a way to better deal with code breakage, so the breakage could be more aggressive. For example, if one could compile together both modules that rely on autodecoding Phobos and modules that rely on non-decoding Phobos, issue fixed.

On Tuesday, 31 March 2020 at 17:52:39 UTC, Mathias LANG wrote:
> Why do you think it would ? At the moment we have a sliding window for deprecation. We'd just change that to have a specific time for removal. I don't see how that would make every release a breaking change ?

Yup, assuming the current 3-month release cadence continues it would make sense to make all breaking changes in only one of those 4 quarterly releases.  A Christmas present to the community? O:-)