On Sat, Nov 1, 2014 at 9:04 AM, Sven Barth <pascaldra...@googlemail.com> wrote:
> On 31.10.2014 00:04, silvioprog wrote: > >> Hello, >> >> Following this article: >> >> http://alex.ciobanu.org/?p=51 >> >> The compiler does not check the constructor restriction. >> >> Try this test: >> >> {$mode delphi} >> >> TTest = class >> private // hidding the constructor to cause a compiler error >> constructor Create; >> end; >> >> TGen<T: class, constructor> = class >> end; >> >> constructor TTest.Create; >> begin >> end; >> >> var Gen: TGen<TTest>; >> begin >> Gen := TGen<TTest>.Create; >> end; >> >> It compiles well in FPC (from trunk), but the same code in XE is: >> >> "[dcc32 Error] Unit1.pas(36): E2513 Type parameter 'T' must have one >> public parameterless constructor named Create" >> >> It is a bug in FPC or I need to enable some directive switch? >> > > "constructor" restrictions are not enforced currently, because with the > way FPC handles generics compared to Delphi they are a bit useless. > Consider this: > > === code begin === > > type > TTest = class > strict private // just to keep it hidden in the same unit > constructor Create; > end; > > var > t: TTest; > begin > t := TTest.Create; > end. > > === code end === > > The above code snippet will compile, because the compiler will use the > next best constructor that it can find which is at least the constructor of > TObject. > > Next snippet: > > === code begin === > > type > TGeneric<T> = class > procedure Test; > end; > > procedure TGeneric<T>.Test; > begin > Writeln(T.Bar); > end; > > begin > end. > > === code end === > > This will correctly compile in FPC, but not in Delphi, because FPC handles > quite some type checking at specialization time not at declaration time. So > this will fail to specialize (at compile time) if T does not implement a > class method called "Bar". > > Now let's put these two concepts together and exchange "T.Bar" with > "T.Create" (and change the "Writeln" to something else of course ;) ) and > it will still compile as long as T provides a Create method. Now as long T > is a class this will always be the case, because there is at least the > TObject constructor. > Indded. Thanks for the explanation brother. =) > That's why the "constructor" constraint is currently not handled in > anyway. That said there'd still be a usecase for this to ensure that there > is a default constructor in the class. Also it might be worthwhile to > rethink the type checking in case of mode Delphi for generics... :/ > It seems good to check it like Delphi em mode delphi, keeping the compatibility. =/ -- Silvio Clécio My public projects - github.com/silvioprog
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
