Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-26 21:59 GMT+02:00 Sven Barth : > First of let me tell you that in essence and in general I'm in support > of your "default" idea > Not only you Sven ;) I found interesting comment by Allen Bauer, seems like "default" idea is right direction. Completely

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 17:03 GMT+02:00 Stefan Glienke : > I agree with Michael here. While in Spring4D our nullables have the > implicit > operator in both directions in retrospective I think it's not a good idea > and > the nullable -> x conversion should be explicit (with the

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 17:58 GMT+02:00 Michael Van Canneyt : > Then you will not have this problem; GetValue will always return a > 'Default' value. IMO bad design. You can't use value of not assigned nilable types as same as you can't use not assigned pointers >.<. There is no

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 16:37 GMT+02:00 Michael Van Canneyt : Are there additional benefits I have missed ? Using nilable (I think nilable is better than nullable) records is terrible without default field: === code begin === var n:

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 17:49 GMT+02:00 Maciej Izak : > === code begin === > > var > n: TNilable; > begin > { > >... let say that n is assigned somewhere, assume that n.HasValue = true > > } > x.foo1 := 10; > x.foo2 := 'abc'; > end. > > === code end === > small typo. n

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 16:37 GMT+02:00 Michael Van Canneyt : > > Are there additional benefits I have missed ? > > Using nilable (I think nilable is better than nullable) records is terrible without default field: === code begin === var n: TNilable; x: TRec; begin { ... let

Re: [fpc-devel] "Default" discussion for SmartPointers etc

> Well, I think this addition is not necessary, maybe even dangerous. > I can live with the 'ascetic' version :-) > > Since the following: > > Procedure SomeTest(Var X : Integer); > > begin >X:=1; > end; > > Var >A : TNullable; > > begin >SomeTest(A^); > end. > > Will lead to a

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Dmitry Boyarintsev wrote: On Thu, Jul 28, 2016 at 10:37 AM, Michael Van Canneyt < mich...@freepascal.org> wrote: [+] Default field (even if it is only syntactic sugar) can-o'worms: Wasn't there a discussion to have multiple default fields depending on the type? [-]

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, Jul 28, 2016 at 10:37 AM, Michael Van Canneyt < mich...@freepascal.org> wrote: > [+] Default field (even if it is only syntactic sugar) > can-o'worms: Wasn't there a discussion to have multiple default fields depending on the type? thanks, Dmitry

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 14:59 GMT+02:00 Michael Van Canneyt : Because with the exception of the ^ operator, I see no need for any special constructions to achieve a "nullable type", except maybe some implicit constructor/destructor ?

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 14:59 GMT+02:00 Michael Van Canneyt : > Because with the exception of the ^ operator, I see no need for any special > constructions to achieve a "nullable type", except maybe some implicit > constructor/destructor ? > procedure with var parameter is special

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 13:30 GMT+02:00 Michael Van Canneyt : Assume a is null before the call to test1: test1(a); That won't compile. 1. What happens if this procedure is empty, i.e. no write is performed ? (or it is performed

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 13:02 GMT+02:00 Stefan Glienke : > One thing that I did not see mentioned here is the fact that introducing > "operator hoisting" by introducing that default feature will not solve > nullables > at all. > In most of cases we can solve that by class operators but I

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 13:30 GMT+02:00 Michael Van Canneyt : > > Assume a is null before the call to test1: > > test1(a); > That won't compile. > > 1. What happens if this procedure is empty, i.e. no write is performed ? >(or it is performed conditionally) >On return, is a

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 12:40 GMT+02:00 Michael Van Canneyt : I don't see how you can solve nullable var parameters in native code. I'd like to present how TNullable works in my implementation (compilable and runable program ;) Yes, I

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 12:40 GMT+02:00 Michael Van Canneyt : > I don't see how you can solve nullable var parameters in native code. > I'd like to present how TNullable works in my implementation (compilable and runable program ;) === code begin === procedure Test1(var x: Integer);

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-28 11:42 GMT+02:00 Sven Barth : > ...That's where Maciej's idea for the "default" keyword came from, cause > that allows something similar for array properties... That is it! Thanks for detailed descriptions for others. All is expressed in right way. --

Re: [fpc-devel] "Default" discussion for SmartPointers etc

One thing that I did not see mentioned here is the fact that introducing "operator hoisting" by introducing that default feature will not solve nullables at all. I think a basic rule of nullables (at least in C# where I know them from) is the fact that operators can only be applied to a nullable

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Sven Barth wrote: Am 27.07.2016 23:27 schrieb "Jonas Maebe" : Before continuing, I think it would be a good idea to look at what the desired concept is exactly (transparent proxy objects/references, thin wrappers that allow to specify some

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Jonas Maebe wrote: On 27/07/16 22:47, Sven Barth wrote: Am 27.07.2016 21:04 schrieb "Maciej Izak" >: In that case SmartPtr/SmartObj/Nullable type has no sense for me. The basic purpose is excluded. You can do that today

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wednesday 27 July 2016 23:27:21 Jonas Maebe wrote: > > Properly designing a new programming language concept is hard, and the > worst thing is that once it's shipped, you are stuck with it basically > forever. I think it needs more than just some example programs and tests > to design one from

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On 27/07/16 22:47, Sven Barth wrote: Am 27.07.2016 21:04 schrieb "Maciej Izak" >: In that case SmartPtr/SmartObj/Nullable type has no sense for me. The basic purpose is excluded. You can do that today by using for example proxyobject._.foo();

Re: [fpc-devel] "Default" discussion for SmartPointers etc

Am 27.07.2016 21:04 schrieb "Maciej Izak" : > > > 2016-07-27 15:33 GMT+02:00 Jonas Maebe : >> >> It would seem better to me that you do have to add something after your proxy object (specify a field, call a method, use proxyobject[x], ...) to get the

Re: [fpc-devel] "Default" discussion for SmartPointers etc

Michael Van Canneyt wrote on Wed, 27 Jul 2016: On Wed, 27 Jul 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 27 Jul 2016: Why not introduce an address operator ? operator @ (T : MyType) : Pointer; It's only needed because Maciej wants the proxy type to behave differently

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 27 Jul 2016: Why not introduce an address operator ? operator @ (T : MyType) : Pointer; It's only needed because Maciej wants the proxy type to behave differently from all other existing types. The solution is

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 27 Jul 2016: On Wed, 27 Jul 2016, Maciej Izak wrote: TNullable = proxy record ... looks good for me, even better than pure record, the context is more clear. Yes. Exactly what Jonas wanted to achieve, I

Re: [fpc-devel] "Default" discussion for SmartPointers etc

Am 27.07.2016 14:12 schrieb "Maciej Izak" : > > > 2016-07-27 13:11 GMT+02:00 Michael Van Canneyt : >> >> Instance: ^T; default; > > > ";" between default and type will not work. > > TNullable = proxy record > ... > > looks good for me, even better than

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Maciej Izak wrote: 2016-07-27 13:11 GMT+02:00 Michael Van Canneyt : Instance: ^T; default; ";" between default and type will not work. Sorry, typo :/ TNullable = proxy record ... looks good for me, even better than pure record, the

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-27 13:11 GMT+02:00 Michael Van Canneyt : > Instance: ^T; default; ";" between default and type will not work. TNullable = proxy record ... looks good for me, even better than pure record, the context is more clear. -- Best regards, Maciej Izak

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-27 11:24 GMT+02:00 Jonas Maebe : > > On a more general note, I think the fact that @recordvar no longer is a > pointer to the record is wrong. You need a different keyword instead of > "record" in that case (or possibly a modifier for the "record" keyword, > like

Re: [fpc-devel] "Default" discussion for SmartPointers etc

Maciej Izak wrote on Wed, 27 Jul 2016: @@ operator is very simple way to determine where you point. In any other case we have casting hell. See below (and more below). @@ exist rather as fulfillment to pa := @a; form tdefault7.pp (anyway is necessary for untyped pointers). You might not like

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-27 10:38 GMT+02:00 Michael Van Canneyt : > > ? A compiler always behaves rational. Not Delphi compiler ;). Check new intrinsic "IsManaged" for XE7 and newer ;) -- Best regards, Maciej Izak ___ fpc-devel maillist -

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Maciej Izak wrote: 3. "default" need to be transparent and usable with existing code base, some compiler magic is part of my further compiler development (I mean here "Storage Modifiers" and ARC objects in DelphiNextgen mode). With current approach is possible to pass

Re: [fpc-devel] "Default" discussion for SmartPointers etc

2016-07-27 10:12 GMT+02:00 Maciej Izak : > TNullable = record > curiosity: Pascal nilable types are more elastic than C# nullable types: Nested "nilable" types are allowed. :) -- Best regards, Maciej Izak ___ fpc-devel maillist

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On 26.07.2016 14:51, Maciej Izak wrote: > Hi, > > Finally I have a working implementation (not published yet) of Smart > Pointers/ARC objects and Nullable (Nilable?) types. I think is worth to > discuss a little about new "default modifier" (which is strictly related > to mentioned structures).

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Tue, 26 Jul 2016, Maciej Izak wrote: Hi, Finally I have a working implementation (not published yet) of Smart Pointers/ARC objects and Nullable (Nilable?) types. I think is worth to discuss a little about new "default modifier" (which is strictly related to mentioned structures). If