Should’t this work? This would be a good way to set default record values but
it doesn’t seem to be supported.
type
TMyRecord = record
public
a: integer;
b: string;
const
default: TMyR
Am Sa., 10. Nov. 2018, 10:06 hat Ryan Joseph
geschrieben:
> Should’t this work? This would be a good way to set default record values
> but it doesn’t seem to be supported.
>
TMyRecord is not yet completely parsed. There could be another field
located behind the "default" constant. Thus using th
Not quite understanding how that’s not entirely parsed by the time you assign
outside of the record. Even so I would expect it to copy what the const was
able to capture, fully parsed or not.
Also, why does it work to do
begin
r := TMyRecord.default;
in the main block?
> On Nov 10, 2018, at
This also fails.
type
TMyRecord = record
public
a: integer;
b: string;
end;
const
TMyRecord_Default: TMyRecord = (a: 100; b: 'foo');
var
r: TMyRecord = TMyRecord_Default;
> On Nov 10, 2018, at 4:55 P
Am 09.11.2018 um 05:20 schrieb Ryan Joseph:
>
>
>> On Nov 9, 2018, at 4:28 AM, Florian Klämpfl wrote:
>>
>> I like the idea of const in generics, but it needs serious cleanup when it's
>> working:
>
> Question: should other consts besides integers be allowed? I don’t think it
> makes sense pe
Am 09.11.2018 um 03:13 schrieb Ryan Joseph:
>
>
>> On Nov 9, 2018, at 4:28 AM, Florian Klämpfl wrote:
>>
>> I like the idea of const in generics, but it needs serious cleanup when it's
>> working:
>> - commit messages like "first commit" are useless
>
> Those are for github so I could share bu
> On Nov 10, 2018, at 7:16 PM, Florian Klämpfl wrote:
>
> This does not prevent you from creating proper commits, especially as the
> patch series from github could be easily
> applied later on to fpc's main repository.
I’ll assume these commits could be public some day then. I originally tho
Am 10.11.2018 um 13:20 schrieb Ryan Joseph:
>>>
- the compiler contains already a type called tgenericdef
>>>
>>> I think I changed that name in the last commit. Btw I made all those types
>>> because I didn’t want to populate the main types like ttypesym with extra
>>> bytes but I don’t kno
Am Sa., 10. Nov. 2018, 12:44 hat Ryan Joseph
geschrieben:
> Not quite understanding how that’s not entirely parsed by the time you
> assign outside of the record. Even so I would expect it to copy what the
> const was able to capture, fully parsed or not.
>
It's not entirely parsed by the time t
> On Nov 10, 2018, at 7:22 PM, Florian Klämpfl wrote:
>
> If you "export" a generic taking a const from a unit, this info has to be
> stored in the ppu.
Can you show a test case I could use to see where this is triggered in the
compiler? I don’t even know where to begin looking.
Regards,
Am Sa., 10. Nov. 2018, 14:47 hat Ryan Joseph
geschrieben:
>
>
> > On Nov 10, 2018, at 7:22 PM, Florian Klämpfl
> wrote:
> >
> > If you "export" a generic taking a const from a unit, this info has to
> be stored in the ppu.
>
> Can you show a test case I could use to see where this is triggered i
On Sat, Nov 10, 2018 at 4:06 AM Ryan Joseph
wrote:
> Should’t this work? This would be a good way to set default record values
> but it doesn’t seem to be supported.
Personally I think the answer here is keep working on your new/alternate
implementation of default field functionality! It's a mi
On Thu, Nov 8, 2018 at 11:50 PM Ryan Joseph
wrote:
> Question: should other consts besides integers be allowed? I don’t think
> it makes sense personally to use strings, floats or sets but maybe I’m
> wrong.
>
As a daily FPC user there's nothing I find more annoying than compiler
restrictions th
> On Nov 11, 2018, at 6:51 AM, Ben Grasset wrote:
>
> Personally I think the answer here is keep working on your new/alternate
> implementation of default field functionality! It's a missing puzzle piece
> for FPC generics in many ways.
>
Not sure how default fields in generics help here. I
On Sat, Nov 10, 2018 at 9:03 PM Ryan Joseph
wrote:
> Not sure how default fields in generics help here. I just thought it would
> be nice if FPC supported this so we can init records at compile time
> easier. I’d prefer default struct fields like C++ has but typed const
> defaults would be an imp
15 matches
Mail list logo