Removed autocasting strings

[mk-soft]

I think it's better to remove the autocasting strings for a better compiler.

[Little John]

This has been discussed extensively before.
However, I think up to now there actually wasn't made an explicit feature request for it.

From me without a doubt: +1

[luis]

I think it's better to remove the autocasting strings for a better compiler.

I think "for a better compiler" is a pretty weak and generic supporting statement.

[Fred]

What is the problem exactly ? If you don't like it, don't use it and you're good. It's a very common feature on all other major compilers and ease the string concatenation. Some bugs are left, right, but they will be fixed. It won't be removed.

[IdeasVacuum]

If you don't like it, don't use it and you're good

Exactly so ~ I think we can all get carried away with unnecessary criticism at times.

[ts-soft]

I love the autocasting and i think, because it is a compiler function, it will be also quicker, than the call of str().

[luis]

If you don't like it, don't use it and you're good

Exactly so

Not really. Autocast in some cases is used even if you are not asking for it, so it's not always a choice like the answer above seems to imply.

Code: Select all

Define a.String, *p.String

a\s = "world"

*p = @a

; explicit string concatenation
Debug "hello " + *p\s ; "hello world"

; the autocast hides the fact you forgot the \s
Debug "hello " + *p ; "hello 123456789"

You forgot the \s, the unintended string is created silently, you can see it here because you are printing it, but that's not always the case.

In past versions it would have raised an error.

So "just don't use it" does not apply.

I love the autocasting and i think, because it is a compiler function, it will be also quicker, than the call of str().

It's generally the same thing, unless the number to be autocasted is a constant, in that case probably is trapped by the constant folding optimization and the target string (or at least the numeric part of it) is created at compile time.

Code: Select all

a$ = "hello"
i = 123

b$ = a$ + i 

b$ = a$ + Str(i)

b$ = a$ + 123 ; const

becomes

Code: Select all

; a$ = "hello"
  MOV    edx,_S1
  LEA    ecx,[v_a$]
  CALL   SYS_FastAllocateStringFree
; i = 123
  MOV    dword [v_i],123
; 
; b$ = a$ + i 
  MOV    edx,dword [v_a$]
  PUSH   dword [_PB_StringBasePosition]
  CALL  _SYS_CopyString@0
  MOV    edx,[_PB_StringBasePosition]
  PUSH   edx
  PUSH   edx
  MOV    eax,dword [v_i]
  CDQ
  PUSH   edx
  PUSH   eax
  CALL  _PB_Str@12
  POP    eax
  PUSH   dword v_b$
  CALL  _SYS_AllocateString4@8
; 
; b$ = a$ + Str(i)
  MOV    edx,dword [v_a$]
  PUSH   dword [_PB_StringBasePosition]
  CALL  _SYS_CopyString@0
  MOV    edx,[_PB_StringBasePosition]
  PUSH   edx
  PUSH   edx
  MOV    eax,dword [v_i]
  CDQ
  PUSH   edx
  PUSH   eax
  CALL  _PB_Str@12
  POP    eax
  PUSH   dword v_b$
  CALL  _SYS_AllocateString4@8
; 
; b$ = a$ + 123
  MOV    edx,dword [v_a$]
  PUSH   dword [_PB_StringBasePosition]
  CALL  _SYS_CopyString@0
  MOV    edx,_S2
  CALL  _SYS_CopyString@0
  PUSH   dword v_b$
  CALL  _SYS_AllocateString4@8
; 

[Little John]

What is the problem exactly ?

During the last weeks, there have been some discussions here where several people wrote about the problems with string autocasting. I don't have a complete list of all those discussions, but for example see
http://purebasic.fr/english/viewtopic.php?f=7&t=53751
http://purebasic.fr/english/viewtopic.php?f=3&t=53850

If you don't like it, don't use it and you're good.

This is not an argument. The behaviour of string autocasting is built into the current version of the PB compiler. A PureBasic programmer doesn't have the choice to switch it on or off. There actually was a feature request for allowing the user to enable/disable string autocasting (see second link above) -- which I personally do not support, because it probably only would increase the confusion.
For problems that did not exist before introduction of string autocasting, see e.g Luis' post above, or my example in the thread to which the first link above points.

It's a very common feature on all other major compilers and ease the string concatenation.

In the past few weeks, several people have expressed here that for them string autocasting causes more problems than it's worth.

[Josh]

I love the string auto-casting. it makes my code extremely more clear to read and so helps me to beware of mistakes.

[Shield]

It's a very common feature on all other major compilers and ease the string concatenation.

Yes, but those features don't have any ambiguities or inconsistencies. Apart from Luis' example, expressions in parenthesis are also not supported.

In my opinion, it doesn't really add anything world-changing to the syntax. In languages that support the features correctly
(and I'm confident existing bugs in PB regarding this will be eliminated soon), I still use ".ToString()" for all the expressions.

Also (maybe that's going to far, but anyway...) compilers such as C# don't do this via an auto-cast feature but rather
via implicit casting operators or conversion interfaces defined for the specific types, i.e. I can write any class that can be
casted implicitly to string or any other type.

I do see benefits of such a feature in PB, as long as it's implemented properly and as long as it doesn't cause unexpected behavior.
While I probably won't use it I see no reason to remove it once the bugs have been fixed.

[BorisTheOld]

What is the problem exactly ? ..............It's a very common feature on all other major compilers and ease the string concatenation......

Not true.

Although most languages allow mixed data types in calculations, they usually don't allow mixing strings with numeric data types.

There are reasons why languages are full of special functions for data conversion. To have PB do it automatically, creates one more way for errors to be introduced.

Please, please, please, allow this feature to be disabled.

[jassing]

Please, please, please, allow this feature to be disabled.

+1 -- I wish it were something (like EnableExplicit) we can turn off/on -- If I want a number to be with a string, I want to use str() (Yes, I know I can still do that) -- I want the compiler to complain if I try to misuse a numeric value and a string value -- because, the way I program, if I have used a numeric to concatenate with a string, it is not what I intended...

[Tenaja]

Please, please, please, allow this feature to be disabled.

+1 -- I wish it were something (like EnableExplicit) we can turn off/on -- If I want a number to be with a string, I want to use str() (Yes, I know I can still do that) -- I want the compiler to complain if I try to misuse a numeric value and a string value -- because, the way I program, if I have used a numeric to concatenate with a string, it is not what I intended...

If I am testing something out, I like the feature. If I have a tiny little program that serves a purpose, I might use it to save time typing.

On the other hand, for my code that is longer than a handful of procs, I would like to disable it, also, to make debugging easier. For that reason, I am...

+1 for adding DisableAutoCast/EnableAutoCast.

[IdeasVacuum]

Define a.String, *p.String

a\s = "world"

*p = @a

; explicit string concatenation
Debug "hello " + *p\s ; "hello world"

; the autocast hides the fact you forgot the \s
Debug "hello " + *p ; "hello 123456789"

Whilst I absolutely have to agree that the above is a perfect example of PB auto-casting a value, I don't agree that you would necessarily forget the \s -you have just typed-in a pointer id which obviously would be a number 100 times out of 100, so if you wanted the string it points to, why would you forget the \s?

Still, if others are adamant that they do forget these things and their forgetfulness is critical, then the choices are:

1) Roll-back to PB4.61 and remove new string auto-casting ~ example above would result in compile error;
2) Enhance string auto-casting ~ example above would trigger a warning that a pointer id is being cast to a string;
3) Provide a switch option/keyword similar to EnableExplicit;

Of the three, at the moment I think (2) is probably the best solution, even though I don't want to use auto-casting anyway. The potential problem with (3) is that it makes the underlying compiler code even more complex, which could lead to much more innocuous errors?

[BorisTheOld]

Whilst I absolutely have to agree that the above is a perfect example of PB auto-casting a value, I don't agree that you would necessarily forget the \s -you have just typed-in a pointer id which obviously would be a number 100 times out of 100, so if you wanted the string it points to, why would you forget the \s?

Still, if others are adamant that they do forget these things and their forgetfulness is critical, then the choices are:

1) Roll-back to PB4.61 and remove new string auto-casting ~ example above would result in compile error;
2) Enhance string auto-casting ~ example above would trigger a warning that a pointer id is being cast to a string;
3) Provide a switch option/keyword similar to EnableExplicit;

Of the three, at the moment I think (2) is probably the best solution, even though I don't want to use auto-casting anyway. The potential problem with (3) is that it makes the underlying compiler code even more complex, which could lead to much more innocuous errors?

That's a specious argument.

By your reckoning, one should not be so foolish as to make coding errors, and requiring PB to test for such errors makes it unnecessarily complex.

Sadly, we mere mortals are not perfect. And if adding a simple test to PB causes it to create errors, perhaps that in itself is a good argument for not abandoning bullet-proof programming practices.