Thread overview
OT: fixing c++ with epochs
Aug 08, 2019
victoroak
Aug 08, 2019
Dukc
Aug 08, 2019
Dukc
Aug 08, 2019
SashaGreat
Aug 08, 2019
12345swordy
Aug 08, 2019
Ethan
Aug 08, 2019
victoroak
Aug 08, 2019
XavierAP
August 08, 2019
https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html

I follow this forum for some time and I saw some discussions about breaking changes and I thought this would be an interesting read.

I think D is too afraid of breaking changes so maybe this could be a way to do it safely.
August 08, 2019
On Thursday, 8 August 2019 at 11:55:16 UTC, victoroak wrote:
> https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html
>
> I follow this forum for some time and I saw some discussions about breaking changes and I thought this would be an interesting read.
>
> I think D is too afraid of breaking changes so maybe this could be a way to do it safely.

If I understood correctly, the idea is that any file can select what version of the language they use? Sounds good IMO, I have also thought that it would be cool if I could define -preview and -revert switches at module level. For library features, something like what Martin Odersky[1] described at DConf2018 might be a good base for a DIP.

The problem is defining how this feature would work with templates that are defined in different contexts, without runtime slowdown. We cannot simply reinstantiate templates for each version of the language/library, as that would lead to horrible bloat.

And another problem, who would be determined and skilled enough to push through a DIP for such a feature? It won't be the easiest one.

1: https://dconf.org/2018/talks/odersky.html
August 08, 2019
On Thursday, 8 August 2019 at 13:37:34 UTC, Dukc wrote:
> For library features, something like what Martin Odersky[1] described at DConf2018 might be a good base for a DIP.
>
> The problem is defining how this feature would work with templates that are defined in different contexts, without runtime slowdown. We cannot simply reinstantiate templates for each version of the language/library, as that would lead to horrible bloat.
>
> And another problem, who would be determined and skilled enough to push through a DIP for such a feature? It won't be the easiest one.
>
> 1: https://dconf.org/2018/talks/odersky.html

Forgot to add: If despite the challeges such feature will be made one day, the potential benefit would be great indeed. For one, goodbye autodecoding!

August 08, 2019
On Thursday, 8 August 2019 at 11:55:16 UTC, victoroak wrote:
> https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html
>
> I follow this forum for some time and I saw some discussions about breaking changes and I thought this would be an interesting read.
>
> I think D is too afraid of breaking changes so maybe this could be a way to do it safely.

I talked about exactly this in another thread: https://forum.dlang.org/post/ctvstjuzjayimyxwsugg@forum.dlang.org

If I'm not mistaken this was written after Rust decide for 2 ~ 3 years review of the language, instead of carrying bad design for the rest of their lives.

I think if Rust succeeded with their plan, C++ will move in this way pretty fast.

Sasha.
August 08, 2019
On Thursday, 8 August 2019 at 11:55:16 UTC, victoroak wrote:
> https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html
>
> I follow this forum for some time and I saw some discussions about breaking changes and I thought this would be an interesting read.
>
> I think D is too afraid of breaking changes so maybe this could be a way to do it safely.

"Make explicit the default, and introduce an implicit keyword"
Yes dear god, yes! This is what d needs to do when introducing implicit conversions.

Alex
August 08, 2019
On Thursday, 8 August 2019 at 11:55:16 UTC, victoroak wrote:
> https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html
>
> I follow this forum for some time and I saw some discussions about breaking changes and I thought this would be an interesting read.
>
> I think D is too afraid of breaking changes so maybe this could be a way to do it safely.

Interesting!
August 08, 2019
On Thursday, 8 August 2019 at 15:15:49 UTC, 12345swordy wrote:
> "Make explicit the default, and introduce an implicit keyword"
> Yes dear god, yes! This is what d needs to do when introducing implicit conversions.
>
> Alex

Actually, I'll add that to my list of "Things we should break and introduce a new major version with" alongside "const by default" and "pure by default".
August 08, 2019
On Thursday, 8 August 2019 at 20:31:46 UTC, Ethan wrote:
> On Thursday, 8 August 2019 at 15:15:49 UTC, 12345swordy wrote:
>> "Make explicit the default, and introduce an implicit keyword"
>> Yes dear god, yes! This is what d needs to do when introducing implicit conversions.
>>
>> Alex
>
> Actually, I'll add that to my list of "Things we should break and introduce a new major version with" alongside "const by default" and "pure by default".

I think @safe by default would be good too. It would help with attribute bloat.