PureBasic Forums - English

In another thread (http://www.purebasic.fr/english/viewtop ... =3&t=53761) I have given my opinion of the new auto-casting feature. I believe it should not be a PB feature, but understand that many users want it.

With auto-casting active, the compiler might accept code that would otherwise be flagged as an error. Therefore, I think this feature should normally be disabled, and should only be enabled by means of a positive action by the programmer.

This could be achieved by means of a compiler setting in preferences, or a command such as "EnableAutoCasting" in the source code.

Thanks

What is the scope of this request?
Just strings? It already exists: Or do you mean to prevent overflow with unequal datatypes passed to procedure parameters?

skywalk wrote:What is the scope of this request?
Just strings? It already exists:

Code: Select all

Debug Str(x) + "x"  ; auto-casting disabled
Debug x + "x"       ; auto-casting enabled

Sigh!!!! Let's keep this serious please.
This string feature is new and I doubt there is much code using it. And since there are already appropriate functions for doing the string transformations, it seems like a good time to introduce an "EnableAutoCasting" command.

I would prefer that all auto-casting be optional, but that won't happen until PB has all the built-in functions for doing numeric and pointer casting. What complicates things is that PB doesn't have a full set of unique data types. Those that do exist have multiple uses, so it's up to the programmer to keep track of things.

I thought I was serious?
Are you requesting a 'String only' feature or more?

How about? wrote:Allow String auto-casting to be enabled/disabled

skywalk wrote:I thought I was serious?

To say, in your example, that it's enabled in one situation and disabled in another is a specious argument. String auto-casting is always active - and that's why it can be such a deadly feature.

The compiler is no longer able to distinguish a valid statement from an invalid statement. Therefore, bugs will almost certainly be intruduced into code without the programmer being aware of it. This might be acceptable for amateur programmers, but not for professionals.

skywalk wrote:Are you requesting a 'String only' feature or more?

More!

Auto-casting of numeric data is already a major feature of the PB syntax, and one learns to live with it. But string auto-casting is one feature too many. I would like to see it removed completely, but I doubt that will happen. That's why I'm making this request to make it optional.

I'd also like to see numeric auto-casting made optional, but this will be a major task. It will require a full range of distinct data types, new statements to perform the conversions from one data type to another, a "cast" statement for handling the casting of pointers, etc, etc.

Fixing the string auto-casting is probably a good place to start, but I also believe that numeric auto-casting should be cleaned up too.

Ok, but I think it would slow down performance with all these castings optional or not?

Explain full scope in topic? wrote:Allow optional String & Numeric auto-casting.

Personally, I would not apply either if they existed.
Especially after the beating I took requesting an optional compiler switch for floating point division!

We're living with (numerical) auto-casting for quite a while and most of the time, we know, what it will do for us. So within some weeks (months, years,...), we will also be possible to handle the casting with strings in most of the cases -- I hope so, at least

But you can check your knowledge by this autocasting quiz (with no single string casting )...

What will be the debug output when running this code?

Allow auto-casting to be enabled/disabled

-1

That would make the code less comprehensible, and would cause more problems than it's worth.

I personally would like the new string-autocasting to be completely removed.
For reason see this thread.

Little John wrote:

Allow auto-casting to be enabled/disabled

-1

That would make the code less comprehensible, and would cause more problems than it's worth.

I personally would like the new string-autocasting to be completely removed.
For reason see this thread.

I agree with you completely.

String auto-casting is a bad feature, however it exists and the PB guru's obviously think it's a desirable feature. That's why I suggested making it optional, with the default being "disabled". Let those who want it live with the consequences.

I would also like to see the removal of numeric auto-casting, but that's even less likely to happen. So making it optional is as good as we can expect.

I can't see your problem. It doesn't break your old code and the new system of auto-casting is easy and absolute clear. It makes in many cases a better readable code.

I think, it's like in many cases. The problem is not the new feature, the problem is sitting in front of the screen.

Ihhhh, there is something new. I don't need it, I don't like it, it's bad.

If you don't like it, don't use it.

Josh wrote:I can't see your problem. It doesn't break your old code and the new system of auto-casting is easy and absolute clear. It makes in many cases a better readable code.

If you don't like it, don't use it

+1

Josh wrote:I can't see your problem. It doesn't break your old code and the new system of auto-casting is easy and absolute clear. It makes in many cases a better readable code.

I think, it's like in many cases. The problem is not the new feature, the problem is sitting in front of the screen.

Ihhhh, there is something new. I don't need it, I don't like it, it's bad.

If you don't like it, don't use it.

It's there, and I have no choice but to accept the compiler's actions. However, you assume that everyone writes perfect code.
The compiler assumes I wish to cast the numerical value *x2 to a string, but I had intended to type *p\s.

I get no compile error, and that's why this feature is bad and should be removed.

How is this different from a situation where you use a wrong variable but of matching type? Who protects you from that mistake?

freak wrote:How is this different from a situation where you use a wrong variable but of matching type? Who protects you from that mistake?

You can go either way -- strong typing or loose typing.
Personally, I prefer a strong typed language, so that if you make a mistake, the compiler complains... if I want to include a number in a string, I use a function to convert it. If I use a string as a number, I want to convert it... I don't want to rely on a compiler that changes... one year auto casting helps, another, it causes (previously ok) code to now be error filled.

Pick a method, stick with it. (I vote for dropping the numeric to string auto-casting) but if you're going to auto-cast, it should be across the board with everything -- ie:

myvar = 2
result = "3.14" * myvar
and
myvar.s = 2 should also be valid then....

Programmers make mistakes. Sometimes it is just a small typo that can introduce a hard-to-find bug in your code.
We have seen it in the past, without EnableExplicit. A small typo somewhere in a big source and you had created a bug.

EnableExplicit was added to prevent such errors. Many users here use EnableExplicit, because it helps them to
find and prevent such errors, mistakes, typos. EnableExplicit forces the compiler to do more strict checks.

The new compiler feature of auto-casting numeric values into strings softens the more strict compiler checks,
so it creates again a new possibility to miss errors and typos in your code. It is what BorisTheOld is saying here.

Instead of softening compiler checks again, he wants more strict compiler checking, like it was introduced with EnableExplicit.
And he is asking to make it optional. Again, like EnableExplicit. We can use EnableExplicit to force stricter compiler checks,
and it helps us.
If you don't want to use the strict checks, you don't use EnableExplicit. We see questions here in forum from time to time,
where the answer is as simple as: "Use EnableExplicit and you see your mistake!"

You wanted to write:but you made a small typo: Now, with the softened compiler checks because of auto-casting numeric values into strings, this coding mistake
is not reported by the compiler anymore. It was reported before.
Actually there is a compiler check removed, by introducing a new feature. It's a side-effect,
and BorisTheOld is simply requesting the more stricter compiler checks to come back optionally.

Similar to optional EnableExplicit, that we use to force stricter compiler checks. More stricter checks help us to prevent mistakes.


Just explaining in more detail... because I see and understand the point in BorisTheOld's request.