More strict Cast/Cptr behaviour?

[fxm]

There is already an alias for '@variable' which is 'Varptr(variable)', but they call the same operator.

[Lost Zergling]

Hello. Using older fbc version it is said about Cptr :
"Cptr : Note: Currently, FB does not actually enforce that PointerDataType must be a pointer. This will likely change in future versions though. "
The topic's subject here : "Currently Cast and Cptr are the same, except that Cptr only works with pointers."
I think this behaviour may explain the wide use of Cast because of implicit "syntaxic overload" (hum) of Cptr
MOD wrote (2 years ago) :
"I really don't like the idea of breaking code, especially if it's the casting operator (which is for sure used a lot in bigger projects)." I agree.
I'd like to point out two ideas :
First, the changes needs to be anticipate in the documentation of previous and latest versions
Second, let's not forget Basic is Basic. Nothing against object oriented functions/behaviours, we just have a structured langage that behaves from c to c++ depending on the coding style. This so powerfull, pretty fine, ok thrue, but,.. my worry is about mixed syntax. Confusing.
Like what have been done with Threads, I think the very object-oriented syntax should/could be a bit more explicit (ObjCast() operator/keyword ?).
Same with @
Object programming is unavoidable, other hand, I'll be pretty upset if my beloved FreeBasic appends to become a C++ vulgarilis.
Really.

[fxm]

- Especially that it is easier to avoid any infinite loop for the 'Cast' operator overloading (by defining in it for example a matched constructor or 'Let' operator) than for the '@' operator overloading (by defining for it a base type).

Example for avoiding an infinite loop due to 'Return This' in the Cast operator body.
Uncomment the first or second line to define a matched constructor or let operator:
(in case of both, the constructor takes priority over let operator)

Code: Select all

'#define Ctor
'#define LetOp

#ifdef Ctor
Type _UDT As UDT
#endif
#ifdef LetOp
Type _UDT As UDT
#endif

Type UDT0
  Dim As Integer I = 123
  #ifdef Ctor
  Declare Constructor ()
  Declare Constructor (Byref u As _UDT)
  #endif
  #ifdef LetOp
  Declare Operator Let (Byref u As _UDT)
  #endif
End Type

#ifdef Ctor
Constructor UDT0 ()
End Constructor
#endif

Type UDT Extends UDT0
  Declare Operator Cast As UDT0
End Type

Operator UDT.Cast () As UDT0
  Print "UDT.Cast() As UDT0"
  Return This
End Operator

#ifdef Ctor
Constructor UDT0 (Byref u As UDT)
  Print "UDT0.Constructor(Byref As UDT)"
  This.I = u.I
End Constructor
#endif

#ifdef LetOp
Operator UDT0.Let (Byref u As _UDT)
  Print "UDT0.Let(Byref As UDT)"
  This.I = u.I
End Operator
#endif


Dim As UDT u

Print Cast(UDT0, u).I

Sleep

[fxm]

- So seen the above example, I think that the problem for the 'Cast' operator in UDT is not due to its precise returning type, but rather when it contains an expression like 'Return UDT_instance' or 'Operator = UDT_instance' whatever its return type (built-in type or other UDT) but by value (except if a matched constructor or let operator is defined in the case of return type being other UDT).
- This is worse for the '@' operator which must never use 'Return @UDT_instance' or 'Operator = @UDT_instance'.

After all these considerations, I think we should remove the restriction on this particular returning type of the 'Cast' operator because alone it is not justified.

[speedfixer]

...
Second, let's not forget Basic is Basic.
...

If FreeBASIC is now called stable, then all of Lost Zerglings points should be honored.

I still consider myself a beginner, here, but I also have 25k + lines of code that will have to be adjusted.

The attractiveness of my choosing FB in the first place was that it was NOT c++, but borrowed many of its advanced features that gave this flavor BASIC more flexibility. I'm sure that is true for many new people that come to FB.

I don't want FB to be frozen in stone.

I DO question why the push is always to make FB more llike c++, or why some of the 'features' broken since ancient times can't be fixed.

David

[speedfixer]

And perhaps I am quite out-of-place, on these next comments, but sometimes I just have to express myself to feel comfortable.


edited:
[comments removed]

I expressed - that is enough: I am comfortable.
Does not need to remain for posterity.


david

[fxm]

My last proposal is now to release a constraint (no fully justified), thus keeping the compatibility with old code.
His own reflections written in posts, even without response, force the author to formalize his thought, and so to make its own contradiction.

[fxm]

I added finally a warning note at page Operator CAST:

.....
Warning: For a Cast operator that returns by value (no byref), do not use generally an exit code like Return expression (or Operator = expression) if expression is an instance of typename.
Such a Cast operator code will induce an infinite loop when called, unless an implicit conversion from typename to datatype already exists through a matched constructor (or a let operator) for datatype, so with a higher priority.

[edit]
Last wiki update.

[fxm]

In the documentation warning note (see above), I stayed purely factual without addressing the interest of wanting encode such a type of overloaded Cast operator that implicitly calls a constructor or a Let operator at the end when returning.

[Tourist Trap]

I added a warning note at page Operator CAST:

.....
Warning: For a Cast operator that returns by value (no byref), do not use generally an exit code like Return expression (or Operator = expression) if expression is an instance of typename.
Such a Cast operator code will induce an infinite loop when called, unless an implicit conversion from typename to datatype already exists by using a copy constructor or a let operator (so with a higher priority).

Nice to add this in the doc (it would be very hard to discover the workaround without a little hint).
Cast is quite a passionating keyword.

Still sad that infinite loop is not triggering more explicit compiler warning. It occurs relatively often for me (with properties rather than functions indeed)..

In the documentation warning note (see above), I stayed purely factual without addressing the interest of wanting encode such a type of overloaded Cast operator that implicitly calls a copy constructor or a Let operator at the end when returning.

You are right. We maybe dont have immediate cases where mirror Cast could be used but this capability is quite natural by itself, and has certainly applications depending on what we need to model.

[fxm]

Still sad that infinite loop is not triggering more explicit compiler warning. It occurs relatively often for me (with properties rather than functions indeed)..

Some loopback cases could be easily detected by the compiler.
But loopback does not necessarily mean infinite loop. This can only be a desired recursion (finite loop).
I think we cannot accept that there is a compiler warning for each coded recursive function.
A correct recursion is already often difficult to code by the user, then I see no simple rules to put in the compiler.

In the documentation warning note (see above), I stayed purely factual without addressing the interest of wanting encode such a type of overloaded Cast operator that implicitly calls a copy constructor or a Let operator at the end when returning.

You are right. We maybe dont have immediate cases where mirror Cast could be used but this capability is quite natural by itself, and has certainly applications depending on what we need to model.

By cons, the forum is the proper place for this kind of discussion.

[Tourist Trap]

I think we cannot accept that there is a compiler warning for each coded recursive function.
A correct recursion is already often difficult to code by the user, then I see no simple rules

It could be a set of warnings dedicated to recursion added only on a compiler option, say "-recurs". Hidden code to profile the stack depletion could be added there (as discussed in the other topic). About detection of recursion. In the case of property the probability of a volunteer recursivity is low, the common mistake is this:

Code: Select all

type UDT
   declare property X() as integer
   private:
      as integer _x
end type
property UDT.X() as integer
     return x
end property

For the coder it's a silly mistake but can be hard to detect (crash is silent, not very visible). For the compiler it could be obvious.
This is only a remark. Nothing crucial here.

[Lost Zergling]

@fxm. Note. I wrote my topic because I was afraid about evocating changes with the @operator behaviour (see previous posts with adressof and VarPtr and previous posts with Cast). Please do not consider it as a critic for the job you are doing here. Amicalement.

[fxm]

@Lost Zergling.
I guess now all your fears are gone.
I came back on my first mention for changing, and now I propose not to touch the @ operator, and even to remove the small use restriction for the Cast operator.
(but I think that in the end, we will do nothing).
Cordialement.

[fxm]

Implicit conversions through UDT member procedures with access rights

- When the compiler has the choice between several conversion ways (several possible candidates through several UDT member procedures explicitly defined), the compiler always chooses the higher priority candidate for conversion (versus the context), whatever the access rights to the different candidates.
- Therefore if the explicit higher priority procedure cannot be accessed due to its restricted access right, a compiler error message is returned, and the compiler does not try to test the access of the second priority candidate.