Recent

Author Topic: FPC feature request/suggestion  (Read 12075 times)

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: FPC feature request/suggestion
« Reply #15 on: April 05, 2019, 09:50:04 pm »


var is to tell the compiler that the variable should be passed by reference. 
out does exactly the same thing as var, that is, pass by reference but, in addition to that, it lets the compiler know that the variable will be written to,[...]
constref is yet another case of something that does exactly the same thing as var, which is - again - pass by reference but,
Isn't that the complete set of possibilities?
constref = in
out = out
var = inout

To be honest, I don't like the naming, especially of constref. in the wiki it says its for compatibility reasons with other languages. But "var" should work there in the same way?

Something I dislike more, ist the "const" thing, it shouldn't be neccessary. The compiler should allow passing a constant value via "var"-parameter. Technically that should be possible and would simplify the language.
Edit: What I mean is: The language shouldn't be cluttered by new features. It's already hard enough to impossible to understand all the various features.
« Last Edit: April 05, 2019, 09:52:33 pm by kupferstecher »

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC feature request/suggestion
« Reply #16 on: April 05, 2019, 10:04:30 pm »
Isn't that the complete set of possibilities?
constref = in
out = out
var = inout
No, because "var" does not imply "in" (in other words, it doesn't mean the variable is initialized) nor does it imply "out" (it may just be read).  var implies nothing.  The compiler cannot (and in the case of FPC, should not) make any assumptions as to how a "var" will be used.  In some cases, it will only be read, in other cases, only written to and in yet others cases, read and written.   All of those are a correct use of a "var".

Leaving the naming aside.  It's a desirable thing to be able to tell the compiler as much as possible about how a variable is intended to be used because by doing so, the compiler can verify the variable is used as intended.  Without that information, as in the case of "var", it can't because it doesn't have the necessary information.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: FPC feature request/suggestion
« Reply #17 on: April 05, 2019, 10:19:10 pm »
@Marco
"VAR" is a token for read/write.  If for some reason you want to change semantics for warnings for some minor cases, that is the way to go.
var is to tell the compiler that the variable should be passed by reference.

However did you come by that idea?  , it is read/write calling convention semantics.

Some minor attributes for warning delivery/suppression can be postdelivered by directive as I already demonstrated.

Yes, the a warnings-only directive is micromanaging. But even more so is inventing new syntax for it.
« Last Edit: April 05, 2019, 10:20:42 pm by marcov »

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC feature request/suggestion
« Reply #18 on: April 05, 2019, 10:52:10 pm »
@Marco
"VAR" is a token for read/write.  If for some reason you want to change semantics for warnings for some minor cases, that is the way to go.
var is to tell the compiler that the variable should be passed by reference.

However did you come by that idea?  , it is read/write calling convention semantics.
I came to that idea when reading a Pascal standards report written by "some guy" who goes by the name of Niklaus Wirth.  On page 72 of his report he writes:
Quote
In  program  11.2  none  of  the  values  in  array  g  are  altered;  i.e.
g  is  not  a  result.  Consequently  g  could  have  been  defined  as  a
value  parameter  without  affecting  the  end  result.  To  understand
why  this  was  not  done.  it  is  helpful  to  look  at  the
implementation.

A  procedure  call  allocates  a  new  area  for  each  value  parameter;
this  represents  the  local  variable.  The  current  value  of  the
actual  parameter  is  "copied"  into  this  location;  exit  from  the
procedure  simply  releases  this  storage.

If  a  parameter  is  not  used  to  transfer  a  result  of  the
procedure,  a  value  parameter  is  generally  preferred.  The
referencing  is  then  quicker,  and  one  is  protected  against
mistakenly  altering  the  data.  However  in  the  case  where a
parameter  is  of  a  structured  type  (e.g.  an  array),  one  should  be
cautious,  for  the  copying  operation  is  relatively  expensive,  and
the  amount  of  storage  needed  to  allocate  the  copy may  be  large.
Because  referencing  of  each  element  in  the  array  occurs  only
once,  it  is  desirable  to  define  the  parameter  as a  variable
parameter.

That seems to be clear.  var may be used just for performance reasons and avoid potential memory problems.  IOW, there is no implication whatsoever as to what the use of a var is going to be.  The only thing it tells the compiler is that the variable will be passed by reference and absolutely nothing about whether the variable is only read, only written or read and written.

That's where I got that "idea".

Yes, the a warnings-only directive is micromanaging. But even more so is inventing new syntax for it.
To be precise (which is a necessary characteristic when writing compilers), there is no new syntax.  There would be a new keyword which would syntactically take the place of "var", "out" and/or "constref" depending on how the programmer intends to use the variable.

That keyword would provide information to the compiler to allow it to flag potential problems it cannot identify without it.

I can't help but wonder how you allowed the "constref" and "out" "inventions".  Those two things are as useless as "inout" since, according to you, var already does everything they do.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: FPC feature request/suggestion
« Reply #19 on: April 05, 2019, 11:13:10 pm »
I can't help but wonder how you allowed the "constref" and "out" "inventions". 

OUT is delphi, and I was against constref back then, and still am. I also think that should have been solved with directives rather than syntax. It would have made implementing IUnknown a lot easier.


440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC feature request/suggestion
« Reply #20 on: April 06, 2019, 12:13:39 am »
OUT is delphi,
There is nothing wrong with "out".  It gives information to the compiler which in turn allows it to warn a programmer that his/her "out" parameter has not been written to.  That's a good thing.

... and I was against constref back then, and still am. I also think that should have been solved with directives rather than syntax. It would have made implementing IUnknown a lot easier.
is keeping track of the reference count in managed types what makes you avert to "out" and "constref"  ?
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: FPC feature request/suggestion
« Reply #21 on: April 06, 2019, 01:03:36 am »
You are right, it does but, it really shouldn't.
Do you want to enter a new keyword "inout" to fully reproduce the current "var" behavior, but additionally want "var" to behave differently?

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC feature request/suggestion
« Reply #22 on: April 06, 2019, 01:50:36 am »
You are right, it does but, it really shouldn't.
Do you want to enter a new keyword "inout" to fully reproduce the current "var" behavior, but additionally want "var" to behave differently?
No, definitely not.  I don't want "var" to behave any different than it does now.

All I would like to see is an "inout" keyword, that is "variation" of the "var" keyword that let's the compiler know that the variable should be initialized before being passed as a parameter and that the variable should be written to in the function/procedure.  That way the compiler can emit a warning to the programmer if the variable isn't used according to the way it's declared.

To clarify one thing, stopping the compiler from emitting a superfluous hint when an uninitialized variable is passed as a var in no way changes the semantics of var.  It only changes the way the compiler determines when to emit that hint and, to be totally precise, FPC should _not_ be emitting that hint.  That hint is not applicable.   

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

JernejL

  • Jr. Member
  • **
  • Posts: 92
Re: FPC feature request/suggestion
« Reply #23 on: April 06, 2019, 09:02:42 am »
I like this idea, i've had in the past issues using third party code which called procedure passing some data by var but in some conditions it didn't initialize it before calling, and if compiler could warn me, that would save me 2-3 days of debugging.
 

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: FPC feature request/suggestion
« Reply #24 on: April 06, 2019, 03:20:48 pm »
OUT is delphi,
There is nothing wrong with "out".  It gives information to the compiler which in turn allows it to warn a programmer that his/her "out" parameter has not been written to.  That's a good thing.

It was only a note about where it came from. Btw Out parameters are dangerous if you pass the same managed type by const and by out.  e.g. x(s,s); where the first param is out, and the second const.

Quote
... and I was against constref back then, and still am. I also think that should have been solved with directives rather than syntax. It would have made implementing IUnknown a lot easier.
is keeping track of the reference count in managed types what makes you avert to "out" and "constref"  ?

I avoid constref because it is non-delphi. Maybe in time I'll use const [ref], but I now also use Delphi versions that don't have it, so that is far away, even if FPC supported it now.

I don't use out much because I simply rarely feel the need to micromanage beyond VAR, and I have been bitten by the double reference bug (and some cases I didn't cared to research into detail). I suspect it is as much that it can make it harder to debug (more implicit code).

Basically quite minor issues, but the use is IMHO even less. So I generally only use it what it was meant for: interface references.

I'm also against changing source to suppress warnings if they are not outright bugs, I rather use %H- and similar markups systems to remove warnings temporarily from the view, without changing the source.

Then, if I do bughunting sessions, I can unhide and review them, if necessary.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC feature request/suggestion
« Reply #25 on: April 06, 2019, 05:20:10 pm »
Btw Out parameters are dangerous if you pass the same managed type by const and by out.  e.g. x(s,s); where the first param is out, and the second const.
<snip>
I avoid constref because it is non-delphi.
<snip>
I don't use out much because I simply rarely feel the need to micromanage beyond VAR, and I have been bitten by the double reference bug (and some cases I didn't cared to research into detail). I suspect it is as much that it can make it harder to debug (more implicit code).
I wouldn't go as far as saying "out" parameters are dangerous, I'd say it's important for the programmer to know precisely what the compiler does.  "constref" is FPC specific but, it helps ensuring that things that should not change do not change but, you're right, being FPC specific it does causes minor inconveniences when using another Pascal compiler (in my case Delphi 2) but, in spite of that, I use it whenever applicable.

I'm a strong believer in a programmer giving as much information as possible to the compiler, that way the compiler can work for the programmer and verify that what the programmer is doing is consistent with the information the compiler has been given.  It helps overcome the characteristic that making mistakes is human.  It also often helps catching small but, important design mistakes early in the development cycle instead of catching them during system testing when making changes is usually much more laborious and prone to introduce incompatibilities with other modules.

Programmers have to work hard, their compilers should too. :)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: FPC feature request/suggestion
« Reply #26 on: April 06, 2019, 05:28:56 pm »
I wouldn't go as far as saying "out" parameters are dangerous, I'd say it's important for the programmer to know precisely what the compiler does.

  "constref" is FPC specific but, it helps ensuring that things that should not change do not change but, you're right, being FPC specific it does causes minor inconveniences when using another Pascal compiler (in my case Delphi 2) but, in spite of that, I use it whenever applicable.

Afaik D2 doesn't have OUT either (D+). Not that it matters, since old Delphis are Windows/x86 only, and on Windows/x86 "CONST" generally is equal to constref. That's why constref and const [ref] came relatively late in the life of both compilers. It matters most for systems whose C/C++ ABI defines const NOT by reference.

The point is that micromanaging both (at the risk of introducing hard to debug mistakes) is simply use VAR and ignore some warnings. IOW no risk without any real downsides.

Quote
I'm a strong believer in a programmer giving as much information as possible to the compiler, that way the compiler can work for the programmer and verify that what the programmer is doing is consistent with the information the compiler has been given. 

Then CONST is usually better than constref, since that allows the compiler to decide what is most advantageous.

Quote
It helps overcome the characteristic that making mistakes is human.  It also often helps catching small but, important design mistakes early in the development cycle instead of catching them during system testing when making changes is usually much more laborious and prone to introduce incompatibilities with other modules.

My experience is the opposite. Micromanaging these things, and making unnecessary modifications increase the risk more than lower it. The risks for mistakes with later modifications also increases if you don't grasp all consequences immediately. IOW the KISS principle applies.


440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC feature request/suggestion
« Reply #27 on: April 06, 2019, 05:35:46 pm »
The risks for mistakes with later modifications also increases if you don't grasp all consequences immediately. IOW the KISS principle applies.
That reminds me what a smart guy said (his name was Einstein) "make things as simple as possible but no simpler".  I think he had point. :)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: FPC feature request/suggestion
« Reply #28 on: April 06, 2019, 05:48:05 pm »
All I would like to see is an "inout" keyword, that is "variation" of the "var" keyword that let's the compiler know that the variable should be initialized before being passed as a parameter and that the variable should be written to in the function/procedure.  That way the compiler can emit a warning to the programmer if the variable isn't used according to the way it's declared.
The compiler already knows if the variable is initialized and gives a hint. Do you want it to issue a warning for that with new syntax?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: FPC feature request/suggestion
« Reply #29 on: April 06, 2019, 06:26:55 pm »
The risks for mistakes with later modifications also increases if you don't grasp all consequences immediately. IOW the KISS principle applies.
That reminds me what a smart guy said (his name was Einstein) "make things as simple as possible but no simpler".  I think he had point. :)

That remind me of "The dose makes the poison" (Latin: sola dosis facit venenum), accredited to Paracelsus.

A bit of calling convention and warning management is good. Obsessing about it a poison.

 

TinyPortal © 2005-2018