Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the Set methods be removed? #30744

Closed
aaronfranke opened this issue Jul 22, 2019 · 1 comment · Fixed by #30774
Closed

Should the Set methods be removed? #30744

aaronfranke opened this issue Jul 22, 2019 · 1 comment · Fixed by #30774

Comments

@aaronfranke
Copy link
Member

aaronfranke commented Jul 22, 2019

@neikeq So basically, this code fails with a compiler error:

Transform.origin = Vector2.Zero; // Error CS1612 cannot modify return value.

I assumed that the Set method was a way to work around this problem:

Transform.origin.Set(Vector2.Zero);

But after actually testing this... this code silently fails and does nothing at all! It seems that the Set() methods only work with variables that are otherwise settable with =:

Vector2 a = Vector2.One;
a.Set(Vector2.Zero); // Works.
a = Vector2.Zero; // Or you can just do this...

Considering that they add nothing new and can silently fail, they should probably be removed.

If you run a blame on this file, you will see that Vector2's Set was added by... uh... me... but I was just trying to make Vectors consistent with Quat which already had this.

Quat also has set() in core, which is where it came from, so is / was there a purpose to Quat's set() method and what was it, and should it be removed too? It seems to have existed before @akien-mga's very musical commit (cc @reduz). I know that, for example, this works just fine in GDScript:

transform.origin = Vector2.ZERO # Works

So, it's a good thing that @akien-mga rejected me adding this into core, as not only is it not a problem in GDScript, but also the "solution" doesn't work either...

Sorry for the long post, but I just wanted to post the whole story of Set() to my knowledge.

@aaronfranke aaronfranke changed the title [Mono] Should the Set methods be removed? Should the Set methods be removed? Jul 22, 2019
@neikeq
Copy link
Contributor

neikeq commented Jul 22, 2019

Indeed, the compiler doesn't give an error CS1612 for methods that mutate the struct. We should deprecate all such methods. Given the severity of this, it may be better to forbid using them entirely with [Obsolete("...", error: true)].

Here is what I found from a quick look:

  • Vector2 -> Set(Vector2), Set(real_t, real_t)
  • Vector3 -> Set(Vector3), Set(real_t, real_t, real_t)
  • Quat -> Set(Quat), Set(real_t, real_t, real_t, real_t), SetAxisAngle(Vector3, real_t), SetEuler(Vector3)

None of these methods need an immutable replacement:

  • The Set methods should be replaced with assignments.
  • q.SetAxisAngle(axis, angle); should be replaced with q = new Quat(axis, angle);.
  • q.SetEuler(eulerYXZ); should be replaced with q = new Quat(eulerYXZ);. Although I find the latter would be better as Quat.FromEuler(eulerYXZ) instead of a constructor.

@neikeq neikeq added this to the 3.2 milestone Jul 22, 2019
@aaronfranke aaronfranke changed the title Should the Set methods be removed? Should Quat's Set methods be removed? Nov 4, 2020
@aaronfranke aaronfranke changed the title Should Quat's Set methods be removed? Should the Set methods be removed? Nov 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants