Allow auto-casting to be enabled/disabled

[luis]

I feel dirty, I fully agree with Danilo's post.

[freak]

Without the autocast you catch only the one specific kind of error where you make a mistake that just happens to end up in a type mismatch by luck. If the types match up, no amount of type checking will catch your mistake.

The notion that this new feature somehow makes it impossible to write correct programs is just making mountains out of mole hills.

[luis]

Without the autocast you catch only the one specific kind of error where you make a mistake that just happens to end up in a type mismatch by luck. If the types match up, no amount of type checking will catch your mistake.

Yup, your point is certainly well taken but no one in his right mind expect the compiler to catch an error like that.

The notion that this new feature somehow makes it impossible to write correct programs is just making mountains out of mole hills.

Someone said that ? Impossible ?
I only saw some people complaining about the fact this new thing added a possible new kind of undetectable error in exchange for a frivolous advantage. You can now avoid to write str(). Only sometimes though. I didn't look forward to it but I don't expect others to feel the same. It's ok.

Anyway, it's only a consideration. A real one. So cannot be so bad.
We know it will stay as it is, but chatting about it it's not a bad thing. Being aware and bring attention to things like these always help.

[skywalk]

These are really good points.
Like freak says, a programmer can always make a mistake.
I am in the camp that 'string + number' should be disallowed.
But if it is to be kept, '(string + number) + string' must be allowed.
Else, this is a half hearted approach to simplify concatenating strings.
freak says parentheses are not needed since you can use 'string + Str(number) + string'.
But that brings the question, why allow the mix only half-way?

Probably too hard to answer, but how would compile speed be affected by disabling numeric auto-casting?
And, wouldn't we need a whole bunch of type conversion functions like CDbl(x.f) and CInt(x.d)?

[Danilo]

The notion that this new feature somehow makes it impossible to write correct programs is just making mountains out of mole hills.

It is not impossible to write correct programs with this new feature. I just explained the point in more detail, it is not my opinion.

1.) I see BorisTheOld's point and understand it as explained it in my last posting.
2.) Saying "just don't use the new feature" is like saying "just don't make typos"
3.) Removing the new feature is not an option, as some people like the new feature already.
4.) Making all new features optional from now on, would create a mess.

Just giving some thoughts here. I don't have a personal opinion about it yet, because it is not as easy at it seems at first.
I see contrary points here... and I understand all of them.

We discuss it and give thoughts, the PB team decides how they want PB to be. The creators of PB seem to have made their decision already.
As I see contrary points, it is logical to me some people don't agree here. Contrary points, contrary opinions...

At the end it seems to come down to the simple question: Do you want more strict or more loose compiler checks in PureBasic?

Again: Different people, different answers.

[LuCiFeR[SD]]

There is an example from a few weeks ago which I am going to use which involved a misunderstanding of how somebody thought Val() could be used with Round() instead of ValF(). Now this is not in any way intended to insult or belittle anybody... but if something as simple as that can be abused, and then we put it into an auto-casting scenario.... how do you think future bug reports will be? And this is exactly WHY we should be questioning decisions like this...

Not that my opinion counts for anything, but to be honest, ANY language change which impacts how I write my code *IS* important. And something as important as this will affect whether I continue to use PB.

The last thing I want to see is some half baked idea which hasn't been properly thought through implemented, which may or may not break my code. So far, I have avoided such traps as pointers changing (because I didn't use types with them) although, I did get caught out with labels becoming local (and if you haven't been caught out by that yet... hehehe, you deserve my respect!)

if there is one thing that REALLY fucking annoys me with any language is syntax change. I like things to be consistent. I like to be able to compile code from 10 years ago with no changes whatsoever. And real fundamental changes to a language like this are just going to break everything like it has never been broken before! I really implore each and every one of you to really think hard about anything which could break old code. and if it *DOES* have to be broken, how to get the compiler to tell you how to fix it! because short of rewriting every bit of code that passes before it from every forum post manually...... how do we deal with this?

[Danilo]

And something as important as this will affect whether I continue to use PB. It really is that simple.

It again comes down to the simple question: Do you want more strict or more loose compiler checks in PureBasic?

Just another thought: I like both. I like strict typed programming languages for creating big programs, more complex systems. It helps me, as correctness is most important in this case.
I like less strict programming languages for prototyping and writing small tools very fast. It helps me to create things much faster. Programming speed is most important here.

There are programming languages available for both styles. Very strict rules (C for example) and very loose rules (many dynamic languages).

PureBasic is something in between, with a tendency to more loose rules (in my opinion).

Could it be the point here? Some people want PB to be more strict. It seems to be the same people who use PureBasic
for creating large projects. Other programmers don't want PB to be too strict, as they can write code faster for prototyping
and small tools.

Not easy to find the right balance in between contrary systems.

[LuCiFeR[SD]]

I suppose I would prefer the language to be more strict if I am honest. I am not as skilled a programmer when it comes to WinAPI as you as an example, but the reason I am here at all speaks volumes. I do love this language, for all my bluster and temper tantrums hehe.

I just don't want to see insane decisions made to the language. Ok, maybe I genuinely am in the minority.... but this to me is extremely important. I do program in C and asm, but there are people with a lot more knowledge than I. and again, I am the first to admit that you are one of them... My knowledge is from the amiga days, I am not exactly what you would call "modern and up to date" with any language. I just know what I personally feel comfortable with. And the direction PB is taking currently is not comfortable for me. Not at all comfortable.

Maybe what I said in my earlier post was a little harsh and unfair, but... meh! I am a man of instinct, and somehow, a lot of these recent changes are horribly wrong.

[Thunder93]

Hi. Not for or against. I find discussions like these very interesting and informative. That being said, I personally think that there are more important things for the PB development team to be focusing on and still bugs to be squashed. I like the dedication I'm seeing from the PB development team and its customers on here, kudos to you all!

[Danilo]

I find discussions like these very interesting and informative. That being said, I personally think that there are more important things for the PB development team to be focusing on and still bugs to be squashed.

We usually don't discuss new features that hefty. New features are very welcome any time!

This time it is about a major change in the programming language design. More strict rules vs. more loose rules.
If the outcome of the discussion would be to please everyone, It was worth it.

Maybe switching between contrary programming styles within one programming language would indeed be the perfect, the ultimate thing.

EnableStrict / DisableStrict ?

[Little John]

Without the autocast you catch only the one specific kind of error where you make a mistake that just happens to end up in a type mismatch by luck. If the types match up, no amount of type checking will catch your mistake.

This is true ... so what?
Nobody said that disabling autocasting will prevent all mistakes. But without autocasting, more bugs will be prevented than with autocasting. That's a good thing. To err is human, and it is part of the compiler's job to catch as much errors in the code as possible.

The notion that this new feature somehow makes it impossible to write correct programs

Nobody wrote something like that. I do not think that polemics will help here.

I am in the camp that 'string + number' should be disallowed.
But if it is to be kept, '(string + number) + string' must be allowed.
Else, this is a half hearted approach to simplify concatenating strings.
freak says parentheses are not needed since you can use 'string + Str(number) + string'.
But that brings the question, why allow the mix only half-way?

Agreed