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
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
On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote:
On 01/30/2013 10:42 AM, Dicebot wrote:
...
That was the most uneasy part of proposal. I have been
thinking for few
hours about it, considering different options. In the end, I
have
decided that it is only confusing to one coming
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.
My assumption is that I don't
01-Feb-2013 13:34, Dicebot пишет:
On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote:
On 01/30/2013 10:42 AM, Dicebot wrote:
...
That was the most uneasy part of proposal. I have been thinking for few
hours about it, considering different options. In the end, I have
decided that
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
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
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
On Wednesday, 30 January 2013 at 20:22:11 UTC, Jacob Carlborg
wrote:
If you have a public and a private function in the same module,
it's possible to implement the two functions in two separate
object files. The private function must then be available in
the object file to link the program
On Wednesday, 30 January 2013 at 20:22:11 UTC, Jacob Carlborg
wrote:
On 2013-01-30 17:26, deadalnix wrote:
The code is in C in the example. But if you replace the C code
by
another D module, the exact same reasoning holds.
What point are you trying to make by raising that ? It seems
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
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
On Wednesday, 30 January 2013 at 09:42:01 UTC, Dicebot wrote:
On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips
wrote:
And this results in people writing code that ...? Is there an
example where you can break code in another module by changing
something marked as private?
On Wednesday, 30 January 2013 at 09:29:17 UTC, Dicebot wrote:
Case 1 (binary level, C + D):
- sample.d -
module sample;
private int func() { return 42; }
--
- oops.c -
#include stdio.h
extern int _D6sample4funcFZi();
void* _Dmodule_ref = 0;
void*
Case 1 (binary level, C + D):
- sample.d -
module sample;
private int func() { return 42; }
--
- oops.c -
#include stdio.h
extern int _D6sample4funcFZi();
void* _Dmodule_ref = 0;
void* _D15TypeInfo_Struct6__vtblZ = 0;
void _Dmain() { }
int main()
{
long value =
On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips
wrote:
And this results in people writing code that ...? Is there an
example where you can break code in another module by changing
something marked as private?
Examples separated:
On Wednesday, 30 January 2013 at 09:42:01 UTC, Dicebot wrote:
On Wednesday, 30 January 2013 at 05:29:14 UTC, Jesse Phillips
wrote:
And this results in people writing code that ...? Is there an
example where you can break code in another module by changing
something marked as private?
On 2013-01-30 10:57, deadalnix wrote:
I understand the risk of breakage. But . . .
Not worth the breakage.
Is this code supposed to work in the first place ? I mean, the private
function is not marked export, the language make no guarantee it will be
accessible from C.
Additionally, does
On Wednesday, 30 January 2013 at 12:02:46 UTC, Jacob Carlborg
wrote:
It's not just accessing from C code. Due to D supporting
separate compilation you can have the implementation of a
private method in a separate object file.
The code is in C in the example. But if you replace the C code by
On 2013-01-30 17:26, deadalnix wrote:
The code is in C in the example. But if you replace the C code by
another D module, the exact same reasoning holds.
What point are you trying to make by raising that ? It seems completely
irrelevant to me. Or I didn't inferred the part of the reasoning
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or
ability to mark symbols for internal linkage at all? How about
something like @internal?
On 01/29/2013 11:29 AM, Dicebot wrote:
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or ability to
mark symbols for internal linkage at all? How about something like
@internal?
I only oppose changing the meaning of static. I
On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:
On 01/29/2013 11:29 AM, Dicebot wrote:
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or
ability to
mark symbols for internal linkage at all? How about something
On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:
On 01/29/2013 11:29 AM, Dicebot wrote:
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or
ability to
mark symbols for internal linkage at all? How about something
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP22
I think your going to need to give some evidence to the problems
with the current behavior.
dlang.org states that Private module members are equivalent to
static declarations in C programs. but this is
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP22
Error on that page (for C++):
public
Default one, if you can see symbol - you can access it
That is true only for structs. For classes, private is the
default.
See also this:
On Monday, 28 January 2013 at 17:18:27 UTC, eles wrote:
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP22
Error on that page (for C++):
public
Default one, if you can see symbol - you can access it
That is true only for structs. For classes, private is
On 01/28/2013 06:05 PM, 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
On Monday, 28 January 2013 at 17:36:58 UTC, Timon Gehr wrote:
Fixing private is enough.
Not a fan of the static thing at all. It is a great thing that
the static attribute actually has a consistent meaning in D.
mixin template X(){
static int x = 2;
}
class C{
mixin X; // x is a
On 2013-01-28 18:05, 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
30 matches
Mail list logo
