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

2016-07-28 Thread Maciej Izak
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 possibility to > raise an expli

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

2016-07-28 Thread Maciej Izak
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 magic in ^ . Just look at de

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

2016-07-28 Thread Michael Van Canneyt
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: TNilable; x: TRec; begin

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

2016-07-28 Thread Maciej Izak
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 instead of x ;) -- Best

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

2016-07-28 Thread Maciej Izak
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 say that n is assigned s

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

2016-07-28 Thread Stefan Glienke
> 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 c

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

2016-07-28 Thread Michael Van Canneyt
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

2016-07-28 Thread Dmitry Boyarintsev
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

2016-07-28 Thread Michael Van Canneyt
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 ? procedure with var parameter

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

2016-07-28 Thread Maciej Izak
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 case, we need somehow to per

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

2016-07-28 Thread Michael Van Canneyt
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 conditionally) On ret

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

2016-07-28 Thread Maciej Izak
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 think that for few ca

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

2016-07-28 Thread Maciej Izak
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 null or not ? > You are

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

2016-07-28 Thread Michael Van Canneyt
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 remember you demonstrate

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

2016-07-28 Thread Maciej Izak
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); begin x := 1; end; pro

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

2016-07-28 Thread Maciej Izak
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. -- Best regards, Maciej Izak _

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

2016-07-28 Thread 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. 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 i

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

2016-07-28 Thread Michael Van Canneyt
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 default behaviour, nullable typ

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

2016-07-28 Thread Sven Barth
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 default behaviour, nullable types, ... ?) already exists in other programmi