On 12/22/2013 08:48 PM, Martin Nowak wrote:
On 12/22/2013 12:05 AM, Timon Gehr wrote:
How is this going to work?
Ah sorry, I misread your example.
The call template function is in module a, so it has access too.
> Are you arguing for creating multiple instances of 'call'?
So this is inde
On 12/22/2013 12:05 AM, Timon Gehr wrote:
How is this going to work?
Ah sorry, I misread your example.
The call template function is in module a, so it has access too.
> Are you arguing for creating multiple instances of 'call'?
So this is indeed not necessary, the function is called withi
On 12/21/2013 11:56 PM, Martin Nowak wrote:
On 12/21/2013 11:17 PM, Timon Gehr wrote:
...
I see. Then how are you going to handle the following:
module a;
private auto foo(int x){ }
auto foo(double x){ }
auto call(alias a){ a(0); }
void x(){
call!foo(); // ok
}
This will work.
modul
On 12/21/2013 11:17 PM, Timon Gehr wrote:
On 12/21/2013 11:03 PM, Martin Nowak wrote:
On 12/21/2013 10:28 PM, Timon Gehr wrote:
Well, you pass an alias. Are you saying that for alias template
arguments, the scope of the template declaration applies for
accessibility checking? I.e. we cannot pas
On Saturday, 21 December 2013 at 22:14:51 UTC, Martin Nowak wrote:
What? It's a major design win that we don't have to rerun
semantic for every identical instantiation, in the same sense
that we don't have to reinclude header files.
I know that and completely agree with that.
Or are you only
On 12/21/2013 11:03 PM, Martin Nowak wrote:
On 12/21/2013 10:28 PM, Timon Gehr wrote:
Well, you pass an alias. Are you saying that for alias template
arguments, the scope of the template declaration applies for
accessibility checking? I.e. we cannot pass private symbols as alias
arguments? I thi
On 12/21/2013 10:36 PM, Dicebot wrote:
If MUST have different overload resolution if B does not have access to
those A function. Anything else is damn broken module system. Why would
anyone expect to move functions between modules and have accessibility
rules magically persistent?
It's important
On 12/21/2013 10:22 PM, H. S. Teoh wrote:
I was pretty upset when I encountered the following situation:
---std/regex.d---
...
private struct Stack { ... }
...
---mymodule.d---
...
/* public */ struct Stack { ... }
...
---
On 12/21/2013 10:28 PM, Timon Gehr wrote:
Well, you pass an alias. Are you saying that for alias template
arguments, the scope of the template declaration applies for
accessibility checking? I.e. we cannot pass private symbols as alias
arguments? I think this is an unreasonably high price to pay.
On 12/21/2013 10:36 PM, Dicebot wrote:
It is a major design issue with templates using declaration scope for
access resolution instead of instantation scope. I think it was a
mistake and is unrelated to general visibility rules.
I think there is quite some overlap.
On Saturday, 21 December 2013 at 21:14:43 UTC, Martin Nowak wrote:
If I make a refactoring and move a function from module A to B,
but the function calls an overload set in A it should not have
a different overload resolution.
If MUST have different overload resolution if B does not have
acce
On 12/21/2013 10:14 PM, Martin Nowak wrote:
On 12/21/2013 08:54 PM, Dicebot wrote:
On Saturday, 21 December 2013 at 19:29:28 UTC, Martin Nowak wrote:
Still don't understand how intended and expected behavior can be called
"bug".
If I make a refactoring and move a function from module A to B, b
On Sat, Dec 21, 2013 at 10:09:44PM +0100, Martin Nowak wrote:
> On 12/21/2013 09:18 PM, Timon Gehr wrote:
> >On 12/21/2013 08:29 PM, Martin Nowak wrote:
> >>On Saturday, 21 December 2013 at 17:41:32 UTC, Timon Gehr wrote:
> >>>Adding a private symbol to an overload set can break 3rd party code
> >>
On 12/21/2013 08:54 PM, Dicebot wrote:
On Saturday, 21 December 2013 at 19:29:28 UTC, Martin Nowak wrote:
Still don't understand how intended and expected behavior can be called
"bug".
If I make a refactoring and move a function from module A to B, but the
function calls an overload set in A it
On 12/21/2013 09:18 PM, Timon Gehr wrote:
On 12/21/2013 08:29 PM, Martin Nowak wrote:
On Saturday, 21 December 2013 at 17:41:32 UTC, Timon Gehr wrote:
Adding a private symbol to an overload set can break 3rd party code
with these rules.
Yes, this is understood, but it seems like a good tradeo
On 12/21/2013 08:29 PM, Martin Nowak wrote:
On Saturday, 21 December 2013 at 17:41:32 UTC, Timon Gehr wrote:
Adding a private symbol to an overload set can break 3rd party code
with these rules.
Yes, this is understood, but it seems like a good tradeoff when compared
to the alternative where o
On Saturday, 21 December 2013 at 19:29:28 UTC, Martin Nowak wrote:
Yes, this is understood, but it seems like a good tradeoff when
compared to the alternative where overload resolution depends
on look-up origin. The latter could easily break generic code
and simple refactorings could introduce
On Saturday, 21 December 2013 at 17:41:32 UTC, Timon Gehr wrote:
Adding a private symbol to an overload set can break 3rd party
code with these rules.
Yes, this is understood, but it seems like a good tradeoff when
compared to the alternative where overload resolution depends on
look-up origi
On 12/20/2013 09:48 PM, Martin Nowak wrote:
I updated DIP22 - Private symbol visibility with my findings from
implementing the 'Hide module members' pull request.
https://github.com/D-Programming-Language/dmd/pull/739
I don't have much time to cope with the topic but any feed
I don't have anything really substantial to say except that this
looks good to me and i look forward to it being
implemented/pulled.
I updated DIP22 - Private symbol visibility with my findings from
implementing the 'Hide module members' pull request.
https://github.com/D-Programming-Language/dmd/pull/739
I don't have much time to cope with the topic but any feedback is welcome.
21 matches
Mail list logo
