On Friday, 1 February 2013 at 15:08:00 UTC, Leandro Lucarella wrote:
> 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.

There are other languages with modules that also have generics,
although not as powerful as D's templates, surely they could be used as inspiration for how they are storing information on the compiled modules.

--
Paulo

What is wrong about *.di in this regard? Have just checked:

--- main.d ---
import test;

void main()
{
    import std.stdio;
    writeln(func());
}
------

--- test.di ---
module test;
int func();
------

--- test_impl.d ---
module test;

int func()
{
    return private_func();
}

private int private_func()
{
    return 42;
}
------

--- shell ---
$ dmd -c main.d
$ dmd -c test_impl.d
$ dmd -ofa.out main.o test_impl.o
$ ./a.out
42
-------

Am I missing something? Seems legit and pretty close to C++ model to me. You trade CTFE capabilities for more explicit interface.

On 2013-02-01 16:08, Leandro Lucarella wrote:

> 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.
>

In C and C++ you don't have anything to generate them, you need to write them manually. You can do that same with D.

-- 
/Jacob Carlborg

On Friday, 1 February 2013 at 09:36:19 UTC, Dicebot wrote:
> Sorry, did not understand this part. Can you give a more code-ish example?

Sorry I can't. If you see code where function is defined, and the compiler complains it is not defined, it can lead to checking imports and supplied files instead of the cause, "not accessible."

On Thursday, 31 January 2013 at 12:10:29 UTC, Jacob Carlborg wrote:
> On 2013-01-31 11:11, Dicebot wrote:
>
>> Ugh, how can you split module into two source/object files? Naive
>> approach will result in linker error due to multiple definition of
>> ModuleInfo. I did not know it was possible, would have been really cool
>> to have.
>
> I'm not 100% sure if it's possible, but it's theoretically possible.

How _exactly_ is it even theoretically possible in D? Sciolism rarely helps when discussing technical issues.

The hard part regarding separate compilation in D is to determine the object file(s) a template instance is emitted to, and the visibility of the symbol. But whether a private symbol is »leaked« into the public API of a module or not can always be determined by just examining the module in question. So, it should be doable, even though the current DMD implementation has bugs in this regard.

David

On Friday, 1 February 2013 at 09:36:19 UTC, Dicebot wrote:
> On Thursday, 31 January 2013 at 20:43:14 UTC, Jesse Phillips wrote:
>> I meant more that these questions should be answered the DIP page.
>
> Sure, I just want to gather more opinions before doing version 2 of DIP. Most likely will gather all together this weekend.

I think at this point it is amply clear that the introduction of a "static"/"internal" keyword is much more controversial than the change to "private".

Thus, I'd recommend splitting up the DIP, so we can make progress on the "private" issue ASAP.

David

On Thursday, 31 January 2013 at 14:50:05 UTC, Jonathan M Davis wrote:
> On Monday, January 28, 2013 18:05:37 Dicebot wrote:
>> http://wiki.dlang.org/DIP22
>> 
>> There are two important issues with current protection attribute
>> design:
>> 
>> * Senseless name clashes between private and public symbols
>> * No way to specify internal linkage storage class
>> 
>> This DIP addresses both of them with two decoupled proposals:
>> 
>> * Change of private related name resolution rules
>> * Definition of static storage class for module-scope symbols.
>
> I see no point to the internal linkage stuff. What we need is for inaccessible
> symbols to not be put in overload sets. I'm not sure that it really needs to
> be any more complicated than that.
>

exported symbol cannot be optimized as much, as the compiler isn't aware of all calls. GCC people made some measurement about that and it ends up being significant.

On Friday, 1 February 2013 at 15:08:00 UTC, Leandro Lucarella wrote:
> I wonder if it ever will make any sense to compile separately instead of
> all in one go.
>

My current project uses 2.5Gb of memory to compile. It take quite a long time as well. The project isn't that big (between 20000 and 25000 LOC I'd say).

Due to dmd bugs, I cannot compile it separately. I really wish I could.

On Saturday, 2 February 2013 at 13:27:46 UTC, David Nadlinger wrote:
> On Friday, 1 February 2013 at 09:36:19 UTC, Dicebot wrote:
>> On Thursday, 31 January 2013 at 20:43:14 UTC, Jesse Phillips wrote:
>>> I meant more that these questions should be answered the DIP page.
>>
>> Sure, I just want to gather more opinions before doing version 2 of DIP. Most likely will gather all together this weekend.
>
> I think at this point it is amply clear that the introduction of a "static"/"internal" keyword is much more controversial than the change to "private".
>
> Thus, I'd recommend splitting up the DIP, so we can make progress on the "private" issue ASAP.
>
> David

Agree, that was my conclusion, too.

OK, I have finally got to it and separated proposal into http://wiki.dlang.org/DIP22 (private) and http://wiki.dlang.org/DIP22.1 (internal linkage). "Private" proposal is updated according to this discussion. "Internal linkage" proposal is only separated, with no real changes, because I am not sure how it is best to address them now.

Also I am going to be very busy for 2 months or so and if someone wants to volunteer to take this over and push into approval in any shape - I would have been very grateful.