On 5 Apr 2014 21:31, "Iain Buclaw" <ibuc...@gdcproject.org> wrote: > > On 5 Apr 2014 19:55, "Johannes Pfau" <nos...@example.com> wrote: > > > > Am Sun, 6 Apr 2014 02:51:28 +1000 > > schrieb "Daniel Murphy" <yebbliesnos...@gmail.com>: > > > > > "Johannes Pfau" wrote in message > > > news:lhp8h4$2j38$1...@digitalmars.com... > > > > > > > But we'd want this to work/inline nevertheless, right?: > > > > ------------ > > > > void test(const(char)[] a) > > > > { > > > > } > > > > > > > > char[] abc; > > > > test(abc); > > > > ------------ > > > > > > > > Then we still need to tell GCC that const(char)[] is a variant of > > > > char[] or it won't inline. > > > > > > Can you just strip all const/immutable/etc when the type is passed to > > > the backend? > > > > > > > This would impact debug info which is also emitted by the backend. GCC > > supports 'variants' of types which means only different qualifiers but > > the same apart from type qualifiers. We just need to set the variant > > information correctly (e.g. const(char)[] should be recognized as a > > variant of char[]) > > Right, and not having const applied to the type means that gcc might miss an optimisation opportunity. > > In this case however I think that parameters declared in should not be mapped to C-style 'const'. The 'in' keyword is close, but something other.
FORTRAN for instance has intent attributes. --- intent(in) - yes, pass by value, so changes of this are not reflected in outside code. intent(out) - pass somehow by reference, in fact a return argument intent(inout) - pass by reference, normal in/out parameter. --- These are interesting concepts that allows more aggressive optimisation than using C/C++ const/ref type variants. I think gdc should go down this route, but I've never experimented too much round this area.
