Coercion dots between typedef to non-typedef

[billko]

---

wiebe@CARYA wrote:

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?

---

With respect to coercion dots, definitely.

[wiebe@CARYA]

---

@billko wrote:

---

wiebe@CARYA wrote:

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?

---

With respect to coercion dots, definitely.

---

With respect to coercion dots on typed def'd scalar values.

Coercion dots are often not innocent, and should be taken seriously, as a rule.

[billko]

---

wiebe@CARYA wrote:

---

@billko wrote:

---

wiebe@CARYA wrote:

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?

---

With respect to coercion dots, definitely.

---

With respect to coercion dots on typed def'd scalar values.

Coercion dots are often not innocent, and should be taken seriously, as a rule.

---

Didn't you just contradict your first point?

Coercion dots should always be considered - and taken seriously - so you understand what is happening.  Making them go away is, I think, mostly a matter of taste, since the coercion is going to happen whether you let the dot do it, or you do it yourself.  For example, I may do an explicit coercion if it's to an integer (typecasting if an enum) data type so it is plain what it is actually being coerced to.  I'm not aware of a manual coercion that does coercion differently than the dot, but if someone has an example, that would definitely be an eye-opener for me.

[altenbach]

---

@billko wrote:
I'm not aware of a manual coercion that does coercion differently than the dot, but if someone has an example, that would definitely be an eye-opener for me.

---

In my links above I discuss an example where the coercion dot is faster than explicit conversion.

(it's actually 33%slower, but sitll there is a significant difference! I have not tested in the latest LabVIEW version)

[billko]

---

@altenbach wrote:

---

@billko wrote:
I'm not aware of a manual coercion that does coercion differently than the dot, but if someone has an example, that would definitely be an eye-opener for me.

---

In my links above I discuss an example where the coercion dot is faster than explicit conversion.

(it's actually 33%slower, but sitll there is a significant difference! I have not tested in the latest LabVIEW version)

---

I agree.  What I meant was that I knew of no instance where the outcome would be different; I should've worded more concisely.  Coming to that conclusion, I only use it as a "crutch" occasionally, like when coercing one type of integer to another to make sure I'm enforcing a certain data type.  (If I get a coercion dot after an explicit coercion, I must have screwed up somewhere.  Sometimes I get quite confused.)

[wiebe@CARYA]

---

@billko wrote:

---

wiebe@CARYA wrote:

---

@billko wrote:

---

wiebe@CARYA wrote:

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?

---

With respect to coercion dots, definitely.

---

With respect to coercion dots on typed def'd scalar values.

Coercion dots are often not innocent, and should be taken seriously, as a rule.

---

Didn't you just contradict your first point?

---

In the context (with respect to coercion dots on typed def'd scalar values), they are save to ignore.

In general, they are not.

[billko]

---

wiebe@CARYA wrote:

---

@billko wrote:

---

wiebe@CARYA wrote:

---

@billko wrote:

---

wiebe@CARYA wrote:

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?

---

With respect to coercion dots, definitely.

---

With respect to coercion dots on typed def'd scalar values.

Coercion dots are often not innocent, and should be taken seriously, as a rule.

---

Didn't you just contradict your first point?

---

In the context (with respect to coercion dots on typed def'd scalar values), they are save to ignore.

In general, they are not.

---

I wouldn't ignore them, either.  They're telling you "I had to do some fancy footwork to get this to work out" and you should always consider whether or not it was an appropriate action.

Sorry if my previous post felt confrontational.  It wasn't supposed to.  🙂

[altenbach]

A coercion dot is nothing more than the compiler telling you: "Hey, I fixed this for you. Make sure it is really want you want". (It does not mean "Hey, you made a big boo-boo here, you need to make that red disappear at all cost!")

[wiebe@CARYA]

---

@billko wrote:

---

wiebe@CARYA wrote:

---

@billko wrote:

---

wiebe@CARYA wrote:

---

@billko wrote:

---

wiebe@CARYA wrote:

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?

---

With respect to coercion dots, definitely.

---

With respect to coercion dots on typed def'd scalar values.

Coercion dots are often not innocent, and should be taken seriously, as a rule.

---

Didn't you just contradict your first point?

---

In the context (with respect to coercion dots on typed def'd scalar values), they are save to ignore.

In general, they are not.

---

I wouldn't ignore them, either.  They're telling you "I had to do some fancy footwork to get this to work out" and you should always consider whether or not it was an appropriate action.

Sorry if my previous post felt confrontational.  It wasn't supposed to.  🙂

---

That's OK, that happens (quite easily) over text. I imagine how it would sound when talking at a bar with a beer. That usually makes it far less confrontational .

[mthheitor]

Thank you all for helping me.

I removed the type def from the 2d array, so the coercion dot disappeared.

And about the type def booleans, I did nothing, the coercion dots are still there.

But in this case they are harmless. Thanks for teaching me that