Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 6:11 PM, Ben Grasset wrote: > > Also, here's a longer (but much better because it doesn't require the data > type provided by the user to itself be directly assignable to a pointer) > version of that: > That’s getting creative, I like it, thanks. Regards, Ryan

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 5:27 PM, Sven Barth via fpc-devel > wrote: > > Well, in theory you could use a read only index property that returns a > pointer and a write only index property that takes the type as is. > But overloading only based on the result type is not supported. > I was

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ok, after thinking about it for a bit, I decided to go ahead and implement the "customizable leading whitespace" thing right away, as a lot of people seemed to want it, and also because I just realized that it would not be difficult at all to do. So, that said, my Github fork branch

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Sven Barth schrieb am Di., 9. Juli 2019, 07:41: > Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: > > On an extra note, the assembly language produced is not yet optimal, > > so it may end up that an x86-specific implementation will be > > beneficial. TIsNode contains a virtual method named >

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: On an extra note, the assembly language produced is not yet optimal, so it may end up that an x86-specific implementation will be beneficial.  TIsNode contains a virtual method named "DoVariableEnumCheck" that would allow such an extension,

Re: [fpc-devel] [] property overloads

I just encountered something to consider. Should a property be overloadable if the names/args are the same but the return type is different? I think if they are not the same access type (i.e. read/write) then it could work (not sure about the parsing though) but if both are the same access then

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

I disabled it after Pierre pointed out that you couldn't use Pred or Succ with them, so wanted to be consistent, especially as programming them to return the expected value of False of a value falls within a hole is not simple. Still, it's easy enough to re-enable. Gareth aka. Kit On Mon

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel > wrote: > > As Pascal does not allow differentiating between result types this indeed > needs to be/stay forbidden. > There actually is a need to distinguish between getters/setters but the way property syntax works we’re forced

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Mon, 8 Jul 2019, J. Gareth Moreton wrote: I'm a bit late to the party again, but the example of an OpenGL shader has won me over, since game design is one thing I enjoy doing.  I guess I'm still a bit unsure how leading and trailing whitespace should be handled, but as long as it's

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Op 08/07/2019 om 06:27 schreef J. Gareth Moreton: I'm a bit late to the party again, but the example of an OpenGL shader has won me over, since game design is one thing I enjoy doing.  I guess I'm still a bit unsure how leading and trailing whitespace should be handled, but as long as it's

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Mon, Jul 8, 2019 at 8:51 AM Ben Grasset wrote: > I'm probably not gonna be working on that myself any time soon, but > certainly yeah I think that IncludeString has an equal amount of value as a > feature, and would compliment multi-line strings well. > Hmm, perhaps I spoke too soon. The

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 16:10: > I just encountered something to consider. Should a property be > overloadable if the names/args are the same but the return type is > different? I think if they are not the same access type (i.e. read/write) > then it could work (not sure about

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 12:04 PM Ryan Joseph wrote: > There actually is a need to distinguish between getters/setters but the > way property syntax works we’re forced for the return type to be the same > as the input for the setter. This is a problem I faced before where I want > the getter to

Re: [fpc-devel] [] property overloads

> On Jul 8, 2019, at 2:16 PM, Ben Grasset wrote: > > One thing I might point out as a general tip is that you don't really > necessarily *need* an array-style index for the kind of access you seem to be > going for, especially if using something like TValue which has a lot of > assignment

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph wrote: > and it will actually write to the actual record in the array and not a > returned copy. However due to how the properties are currently structured > this means we can’t use the setter without passing pointers > Ah, I see what you mean. Note

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 08.07.2019 17:19, J. Gareth Moreton wrote: I disabled it after Pierre pointed out that you couldn't use Pred or Succ with them, so wanted to be consistent, especially as programming them to return the expected value of False of a value falls within a hole is not simple. Still, it's easy

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Apologies.  I've been getting lost and confused in all the details and am not even sure what people want any more.  What is the consensus from the administrators? Gareth aka. Kit On 08/07/2019 21:00, Ondrej Pokorny wrote: On 08.07.2019 17:19, J. Gareth Moreton wrote: I disabled it after

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 18:04: > > > > On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > As Pascal does not allow differentiating between result types this > indeed needs to be/stay forbidden. > > > > There actually is a

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

I need to know exactly what's been decided upon.  No arguments, no debates, no objections.  What has been accepted as "this is what will be implemented after all parties have been heard"? Because I can't put myself into a meltdown while my neck is being wrung for not doing what people wanted.

Re: [fpc-devel] [] property overloads

On Mon, Jul 8, 2019 at 3:47 PM Ben Grasset wrote: > On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph wrote: > >> and it will actually write to the actual record in the array and not a >> returned copy. However due to how the properties are currently structured >> this means we can’t use the setter

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 08.07.2019 12:39, Giuliano Colla wrote: Il 07/07/2019 07:33, J. Gareth Moreton ha scritto: In the meantime, I'm working on making "as" and "is" work with ordinal types as well as enumerations, although currently some headaches occur if the right-hand side is larger than the CPU word size

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 08.07.2019 02:37, J. Gareth Moreton wrote: Uploaded the latest patch (AS-IS-enum-07.patch) over here and also a test project that evaluates the "is" operator between different ordinal types. I though I convinced you not to disable the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Il 07/07/2019 07:33, J. Gareth Moreton ha scritto: In the meantime, I'm working on making "as" and "is" work with ordinal types as well as enumerations, although currently some headaches occur if the right-hand side is larger than the CPU word size (e.g. Int64 on i386). I'll upload the patch to

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

> On Jul 8, 2019, at 12:27 AM, J. Gareth Moreton > wrote: > > Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing alongside > it, because things like shaders are programs in themselves and may have to be > tested in a third-party application, so including the file directly

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Mon, Jul 8, 2019 at 12:27 AM J. Gareth Moreton wrote: > Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing > alongside it, because things like shaders are programs in themselves and > may have to be tested in a third-party application, so including the > file directly rather