Deprecated operators for DateTime private members

> In fact, most bugfixes are a potential breaking change, when people start > relying on the bug. I'm ok with breaking changes to fix bugs -- especially security / correctness related bugs -- but this is not an example of that. Removing a footgun is admirable, but can be done without breaking e

Deprecated operators for DateTime private members

Not all breaking changes are equally hurting and I disagree that you should strive for 0 breaking changes. In fact, most bugfixes are a potential breaking change, when people start relying on the bug. Breaking changes suck and should be avoided whenever reasonable but shooting for 0 or near 0 b

Deprecated operators for DateTime private members

I struggled with this in my ODBC library as I wanted to encode exactly what the ODBC API returned, so setting the fields manually made sense. Part of the reasoning for this was that time zones are handled by the DB, and may also be manipulated by SQL as well. I didn't want to introduce another

Deprecated operators for DateTime private members

I agree completely. For a post-1.0 language, breaking changes should be extremely rare. I think it is fine to add a permanent deprecation notice without ever removing the code, though. In fact, Java's Date class has been deprecated for over a decade, but will probably never be removed. That's th

Deprecated operators for DateTime private members

**GULPF** , thanks for your answer. OK, I see the problem and I understand the solution implemented. I'm definitely not agree with it though. IMHO, the deprecation should be removed from these operators. The day you remove the assignment operators you'll break my application and I'll need to p

Deprecated operators for DateTime private members

Hello, I'm the author of that commit. You can read about the motivations for this change in these RFCs: * * If you wish to assign to the fields and ending up with an invalid value is not a problem t

Deprecated operators for DateTime private members

**timothee** , your solution (and the alternative ways mentioned in the PR discussion) could be a solution. But the situation is more delicate here. These fields _were_ public, they passed to private in the patch I've mentioned. And the operators (deprecated!) were introduced to overcome the pot

Deprecated operators for DateTime private members

in my own nim fork I'm using `{.privateImport.}` everytime I need an escape hatch to bypass protection in a restricted scope, see

Deprecated operators for DateTime private members

Thanks for you answer, **Hlaaftana**. The question is more wide that just using the assignment in the function I mentioned in my previous post. Even if I could try to use `initDateTime` in this function (if it works) - I have some other places when I use the assignments to modify the fields of `

Deprecated operators for DateTime private members

Sorry, I didn't catch this on your last thread, I'm guessing what you're expected to do is call `initDateTime` with all the fields, though I don't think this is possible to do given you inherit from DateTime. Maybe DateTime should be changed to be non-inheritable. What you probably have to do is

Deprecated operators for DateTime private members

Hello, I see in some members of `DateTime` passed to private (for example, `second`) and the operators `=` were introduced to be able to assign