Am Mo., 12. Nov. 2018, 03:12 hat Ryan Joseph <r...@thealchemistguild.com>
geschrieben:
>
>
> > On Nov 12, 2018, at 12:25 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > I'm not convinced that this feature is really needed, because one can
> simply create a constant and assign that, would transport a clear name as
> well.
>
> This is for runtime though and necessarily for constants. It’s just a
> short hand for initializing records so you don’t need to make boiler plate
> constructors. Often time when you create a new record you add a constructor
> so you can init in one line. Swift and c++ both have this default
> constructor and it’s a nice time saver.
>
> for example:
>
> struct Vec2 {
> float x,y;
> };
>
> int main() {
> Vec2 v = {1,2};
> v = {v.x + 1, v.y + 1};
> return 0;
> }
>
The advantage of the typecast like syntax is that you can get compiler
errors if for whatever reason the order of the fields is changed as they
are all named.
> > But *if* I had to decide I would pick #1, cause then there wouldn't be
> the chance to break existing code if a user decides to add a constructor to
> their record and some other code relies on there not being a constructor.
> Also due to the syntax TYPENAME(FIELDNAME:VALUE[;FIELDNAME:VALUE[;…]]) it's
> in principle possible to have the parser distinguish whether it's a
> typecast or a default constructor.
>
> Yeah there could be name conflicts then. Maybe there should be some way to
> explicitly state you want the constructor with a certain name, i.e.,
>
> type
> TVec2 = record
> x, y: integer;
> constructor create; default;
> end;
>
> ??? I don’t know, just an idea.
>
That is a constructor that takes no arguments. How do you think that is
useful for a constructor that *does* take arguments? That is absolutely not
clear at all for the user.
Regards,
Sven
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
