Feature/times mutators

[survivorm]

No description provided.

[skilchen]

You can't multiply a TimesMutableTypes by another TimesMutableTypes. Thats why in my proposal, i only restricted the first generic type to types defined in times.nim. This restriction is enough to avoid the ambiguity with the mutators in system.nim. The remaining validation can be left to the operations defined in times.nim

[survivorm]

hm. Valid point. But only for *=. I think other procs should remain as is

[survivorm]

done

[survivorm]

@dom96, or anyone else, what's with this request's merge?

[Araq]

@dom96, or anyone else, what's with this request's merge?

Well it has merge conflicts with the current devel version of times.nim, please rebase.

[survivorm]

ok, will fix

[survivorm]

@Araq Done

[Araq]

Er ok, but now it loses the nice runnableExamples (though they are currently not tested because they are in a generic, but still...).

[dom96]

As I've mentioned multiple times, I think this should be implemented generically instead of specifically for each new type.

…

On Wed, 6 Jun 2018, 10:21 Andreas Rumpf, ***@***.***> wrote: Er ok, but now it loses the nice runnableExamples (though they are currently not tested because they are in a generic, but still...). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7806 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPDe9RR4DMZMCX3TTqNtQgPLoZOaCTpks5t558wgaJpZM4T5rju> .

[survivorm]

@dom96 Do you have something SPECIFIC on your mind?
Because from my point of view it looks like: I don't have a decision, but this is incomplete (though current is incomplete too))

[survivorm]

@Araq Added some examples

[dom96]

What I specifically have in mind is a generic proc that works for all types that define +, *, etc. It should be defined in system.nim, this would ensure we don't have to define the mutator for every operator we define.

AFAIK @Araq was saying that + should be defined in terms of += for efficiency reasons. But this PR doesn't even do that, as such it's better to just implement what I'm proposing until we can figure out how to get the more efficient version (which seems rather tough).

[Araq]

AFAIK @Araq was saying that + should be defined in terms of += for efficiency reasons. But this PR doesn't even do that, as such it's better to just implement what I'm proposing until we can figure out how to get the more efficient version (which seems rather tough).

Don't let the perfect be an enemy of the good. And yet another system.nim change is not fine with me.

[survivorm]

@dom96 Let us be clear.
If i understand correctly, you state, that no changes are better. Like it or not, current codebase has about 16 += procs as of today. We are not adding MORE, essentially. We're making them more generic, which i see as a better solution than it's now. Yes, it's not perfect. Yes, i'd like it completely generic, too. But while we don't have it, we may use something better than current. Partial, yes, but you'll still need to clear existing += and others of the like procs then the generic solution is ready. This PR is not adding more work.
About the @Araq 's proposition - i don't know it. If it helps, i may modify this PR accordingly

[survivorm]

@Araq How to restart build checks? They've failed because of the strange bug, not connected with this PR

[dom96]

Don't let the perfect be an enemy of the good. And yet another system.nim change is not fine with me.

Okay, but this isn't the first PR of this kind. We need to sort this out properly eventually.

[survivorm]

@Araq @dom96 Any more reasons not to merge this request?

[survivorm]

@Araq @dom96 Thanks!