DIP22 : Private symbol visibility

[Leandro Lucarella]

Dicebot, el  1 de February a las 10:42 me escribiste:
> Still, no need for internal linkage is felt because D projects are
> very small nowadays and does not involve complex separate
> compilation systems and\or large teams of programmers working on a
> single project. What internal linkage gives you is hard 100%
> guarantee (verified by the compiler) that this piece of code may be
> changed as you wish and it won't affect anything but this module.
> Private can't give such guarantees without code breakage. It is a
> widely used idiom in C/C++ that D currently has no replacement.

Unfortunately D is different in this regard than C/C++ (yes, I said
unfortunately :P). Separate compilation in D is not that useful, as
interfaces are not clearly defined (at a file level). When you import
something, you are importing the implementation, not only the interface.
Is really hard to decouple both in D. I tried to play around with
separate (and incremental) compilation in D without much luck. And
I wonder if it ever will make any sense to compile separately instead of
all in one go.

Because of this, even when I agree about the goodness of "static
linkage" (as in C/C++), I don't see real value in this proposal for D.

PS: Yes, I know there are the .di files, but even trying to use that
    makes thing extremely hard, because you need to parse the whole file
    to generate it and the difference between parsing and compiling is
    not that much. And then, as in C++, you have templates.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION
	-- Crónica TV