Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-03

implicit generic specialization modeswitch name

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ryan Joseph

For my patch https://bugs.freepascal.org/view.php?id=35261 I have named the modeswitch “implicitgenerics” but Florian liked the name “implicitfunctionspecialization” (long but clear were his words). Btw this is the mode switch will allows specialization of generic routines by inferring the types from the parameters.

I have no preference either way but I wanted to ask the list if they had any better ideas to contribute. If there’s nothing better I’ll just defer to what Florian wants.

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Ryan Joseph
Ryan Joseph wrote
For my patch https://bugs.freepascal.org/view.php?id=35261 I have named the modeswitch “implicitgenerics” but Florian liked the name “implicitfunctionspecialization” (long but clear were his words). Btw this is the mode switch will allows specialization of generic routines by inferring the types from the parameters. I have no preference either way but I wanted to ask the list if they had any better ideas to contribute. If there’s nothing better I’ll just defer to what Florian wants.

I agree with Florian that a better name is needed for the modeswitch ("implicitgenerics" as a different meaning in my opinion). But I don't have a better idea than "implicitfunctionspecialization" either...

Regards,
Sven

Reply by email

Bart
to Sven Barth
PM Sven Barth wrote
I agree with Florian that a better name is needed for the modeswitch ("implicitgenerics" as a different meaning in my opinion). But I don't have a better idea than "implicitfunctionspecialization" either...

implicitgenericfunctions?
Just a little bit shorter.

Bart

Reply by email

Sven Barth
to Bart

Bart schrieb am So., 24. März 2019, 17:44:

Show quoted text 10 lines
On Sun, Mar 24, 2019 at 5:18 PM Sven Barth via fpc-devel wrote: > I agree with Florian that a better name is needed for the modeswitch > ("implicitgenerics" as a different meaning in my opinion). But I don't > have a better idea than "implicitfunctionspecialization" either... implicitgenericfunctions? Just a little bit shorter.

No, that has the same wrong connotations. It's about specializations, but "generic" suggests that it's about the declarations.

Regards,
Sven

Reply by email

Ryan Joseph
to Sven Barth

implicitroutinespecialization is one character shorter. ;) It’s maybe more accurate also since Pascal has the distinction between procedure/function.

Because this would be the longest mode switch is this maybe a good candidate for abbreviations? Could be implicitroutinespez or implicitprocspecialization.

There’s the list of other mode switches for some point of reference.

m_class, { delphi class model }
m_objpas, { load objpas unit }
m_result, { result in functions }
m_string_pchar, { pchar 2 string conversion } m_cvar_support, { cvar variable directive } m_nested_comment, { nested comments }
m_tp_procvar, { tp style procvars (no @ needed) } m_mac_procvar, { macpas style procvars }
m_repeat_forward, { repeating forward declarations is needed } m_pointer_2_procedure, { allows the assignement of pointers to procedure variables }
m_autoderef, { does auto dereferencing of struct. vars } m_initfinal, { initialization/finalization for units } m_default_ansistring, { ansistring turned on by default } m_out, { support the calling convention OUT } m_default_para, { support default parameters } m_hintdirective, { support hint directives } m_duplicate_names, { allow locals/paras to have duplicate names of globals } m_property, { allow properties }
m_default_inline, { allow inline proc directive } m_except, { allow exception-related keywords } m_objectivec1, { support interfacing with Objective-C (1.0) } m_objectivec2, { support interfacing with Objective-C (2.0) } m_nested_procvars, { support nested procedural variables } m_non_local_goto, { support non local gotos (like iso pascal) } m_advanced_records, { advanced record syntax with visibility sections, methods and properties } m_isolike_unary_minus, { unary minus like in iso pascal: same precedence level as binary minus/plus } m_systemcodepage, { use system codepage as compiler codepage by default, emit ansistrings with system codepage } m_final_fields, { allows declaring fields as "final", which means they must be initialised in the (class) constructor and are constant from then on (same as final fields in Java) }
m_default_unicodestring, { makes the default string type in $h+ mode unicodestring rather than ansistring; similarly, char becomes unicodechar rather than ansichar } m_type_helpers, { allows the declaration of "type helper" for all supported types (primitive types, records, classes, interfaces) }
m_blocks, { support for http://en.wikipedia.org/wiki/Blocks_(C_language_extension) } m_isolike_io, { I/O as it required by an ISO compatible compiler } m_isolike_program_para, { program parameters as it required by an ISO compatible compiler } m_isolike_mod, { mod operation as it is required by an iso compatible compiler } m_array_operators, { use Delphi compatible array operators instead of custom ones ("+") }

Regards,
Ryan Joseph

Reply by email