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 DateTime now passed to private. So, I would like to understand how should I proceed to access to the fields if one day the deprecated functions will be out of times module.
BTW, your advise about adding the field and not inherit from DateTime is absolutely impossible to use in my case - I have several types with such inheritance, very many things must be changed there.
If you wish to assign to the fields and ending up with an invalid value is not a problem then it's likely that DateTime is not the right type for your use case. Instead you can introduce your own type that only holds the data without performing any validation and convert to a DateTime only when needed (using initDateTime). If you wish to update the fields but also want to end up with a valid value there's currently no other way than calling initDateTime again.
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 pass a lot of time to change it's logic. And I suppose to be not the only one. This is a serious breaking change.
Like krux02 mentioned in the RFC, these changes would cause more problems than they would solve.
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 the right way to do it: nudge people in the right direction, but don't break their code.
BTW, as I mentioned in the PR, it actually already is a breaking change for code that used from times import nil.
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 layer of translation on top of this.
Using initDateTime() means I assume a local time zone, but maybe it's not a local time zone in the DB data so doing this is supplying false information to the user.
One option was forcing times to UTC, but maybe the SQL is actually asking for a different time zone. However times currently only supports local and UTC so this starts to get very messy.
In the end, I used TimeInterval, which I'm not really happy with to be honest. Probably I should just introduce a custom type as @GULPF mentions. Times are one of those seemingly simple yet horrendously complex corner-case situations.
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 breaking changes means you compromise ability to improve the language for all future users for the benefit of the few existing users that are unwilling to accommodate those breaking changes; and then you end up with C++ where you have to live forever with early bad decisions.
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 existing users. Java's Date class has many footguns, but their solution was to create an entirely new package (java.time) which is much better designed.
Nobody gets API design right the first time. But if people are relying on the old API, and it isn't clearly a security / correctness bug, just leave it there and create a new API. In Nim, that could be a new module, or new functions in an existing module. No need to break perfectly-functioning code.
shooting for 0 or near 0 breaking changes means you compromise ability to improve the language for all future users for the benefit of the few existing users that are unwilling to accommodate those breaking changes
Breaking changes punish your most enthusiastic users. It's easy to fix breakages in a small hobby project. For 10,000+ line projects, even superficial breakages can be very labor-intensive to fix. You're punishing the people who invested the most in the language.
Does it make sense to force folks like Status or Beamdog, who have large Nim codebases, to "accommodate" breaking changes, for the sake of hypothetical future users? I suspect those future users will not exist, because no language has become popular while constantly breaking the contract it has with its existing users.
and then you end up with C++ where you have to live forever with early bad decisions.
Languages like C++ and Java are pervasive in part because of their commitment to backwards compatibility. Constantly punishing those who invested in Nim is a great way to ensure that it never reaches escape velocity.