On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
But we _want_ that. The fact that inaccessible functions are even considered
in overload sets is horrible. That's precisely the problem. No inaccessible
functions should be in overload sets. Otherwise, simply adding a private
function to a module ca
On 12/21/2012 8:38 PM, Jonathan M Davis wrote:
The reason it is that way is to avoid having it behave gratuitously
differently than how visibility works within classes and structs.
??? I don't see anything here that would become different between user-defined
types and modules.
All we're reall
Jonathan M Davis:
but generally the worst that they'll do is create slight
overhead because of the cost of default initializing them.
I don't care about that overhead, because the optimizer stages of
compilers take care of removing it in many cases, that's not one
of the main points of spott
On Saturday, December 22, 2012 09:30:15 bearophile wrote:
> Jonathan M Davis:
> > but generally the worst that they'll do is create slight
> > overhead because of the cost of default initializing them.
>
> I don't care about that overhead, because the optimizer stages of
> compilers take care of r
On Saturday, December 22, 2012 00:21:33 Walter Bright wrote:
> On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
> > But we _want_ that. The fact that inaccessible functions are even
> > considered in overload sets is horrible. That's precisely the problem. No
> > inaccessible functions should be in
Jonathan M Davis:
You're basically asking for a feature to be added to the
language so that the compiler will be able to tell you where
your code is messy without complaining about legitimate code,
_and_ your suggestion would make the legitimate code messier.
Here you are right only in princip
On Saturday, December 22, 2012 09:53:48 bearophile wrote:
> Jonathan M Davis:
> > You're basically asking for a feature to be added to the
> > language so that the compiler will be able to tell you where
> > your code is messy without complaining about legitimate code,
> > _and_ your suggestion wou
Walter Bright wrote:
> On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
>> But we _want_ that. The fact that inaccessible functions are even
>> considered
>> in overload sets is horrible. That's precisely the problem. No
>> inaccessible
>> functions should be in overload sets. Otherwise, simply addi
12/22/2012 12:21 PM, Walter Bright пишет:
On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
But we _want_ that. The fact that inaccessible functions are even
considered
in overload sets is horrible. That's precisely the problem. No
inaccessible
functions should be in overload sets. Otherwise, simp
Am 22.12.2012 00:46, schrieb Andrei Alexandrescu:
> On 12/21/12 7:24 AM, Sönke Ludwig wrote:
>> Example generated site is here:
>>
>> http://vibed.org/temp/d-programming-language.org/phobos/index.html
>>
>>
>> Is any further work on this desired?
>
> Thanks for this work! Let me provide a little f
On 12/22/2012 09:21 AM, Walter Bright wrote:
On 12/21/2012 8:38 PM, Jonathan M Davis wrote:
The reason it is that way is to avoid having it behave gratuitously
differently than how visibility works within classes and structs.
??? I don't see anything here that would become different between
us
I wanted to fix
http://d.puremagic.com/issues/show_bug.cgi?id=8936 and I'm
currently trying to compile a little repro case in x64 on windows:
import core.stdc.stdio;
import core.sys.windows.windows;
void bar()
{
throw new Exception("Ex");
}
void foo()
{
bar();
}
void main(str
On 2012-12-21 13:24, Sönke Ludwig wrote:
Is any further work on this desired? If so, what would be the next steps to
integrate it into the
general dlang.org workflow? (or rather, how is that workflow in terms of folder
structure, build
scripts etc.?)
It would also need a phase of bug fixing r
On Monday, 5 November 2012 at 08:53:48 UTC, Johannes Pfau wrote:
As deprecated now allows optional messages some folks have
suggested to
make deprecated behave like in other languages: Warn if
something
deprecated is used, do not print warnings if compiling with
-deprecated.
This would confli
On 12/22/12 3:30 AM, bearophile wrote:
Legitimate uses of unused variables are mostly in library code, or user
code similar to library code. Adding to those variable definitions a
@used is fast and perfectly easy. It's not a "jumping through hoops".
I think this is a reframing we should shun be
On 12/22/12 3:21 AM, Walter Bright wrote:
It's that way in C++ mainly so that it doesn't make the already complex
overloading system even more so. And in 25 years of working with C++,
I've never seen this make anyone's list of horrible things about C++.
I think this is a fallacious argument bec
On 12/22/12 10:16 AM, Jacob Carlborg wrote:
On 2012-12-21 13:24, Sönke Ludwig wrote:
Is any further work on this desired? If so, what would be the next
steps to integrate it into the
general dlang.org workflow? (or rather, how is that workflow in terms
of folder structure, build
scripts etc.?)
On 22.12.2012 13:40, Benjamin Thaut wrote:
I wanted to fix http://d.puremagic.com/issues/show_bug.cgi?id=8936 and
I'm currently trying to compile a little repro case in x64 on windows:
[...]
I compiled with the latest git master branch versions of dmd and
druntime. Druntime was build with th
>> * There's lots of wasted real estate at the top of the page: the source,
>> license, and authors
>> sections are way spaced. They should compactly fill the top of the page.
>
> I'll try to get closer to the original there. There are some differences
> because the current pages
> use a lot of
On 12/22/12 11:49 AM, Sönke Ludwig wrote:
* There's lots of wasted real estate at the top of the page: the source,
license, and authors
sections are way spaced. They should compactly fill the top of the page.
I'll try to get closer to the original there. There are some differences
because the
Am 22.12.2012 17:49, schrieb Sönke Ludwig:
>
> Continuing the thought of screen real estate - shouldn't these sections
> better be at the _bottom_ of
> the page? After all they are just noise for the typical reader and since the
> pages are not as long
> anymore, they still won't get drowned by
On 12/22/12 12:53 PM, Sönke Ludwig wrote:
Am 22.12.2012 17:49, schrieb Sönke Ludwig:
Continuing the thought of screen real estate - shouldn't these sections better
be at the _bottom_ of
the page? After all they are just noise for the typical reader and since the
pages are not as long
anymore,
On Saturday, 22 December 2012 at 17:54:29 UTC, Sönke Ludwig wrote:
In the latest upload a number of items is addressed:
- vertical margins at the top
- redundant column headers
- +/- signs for the package tree
- jumps to line numbers on github (which are off because of
changes after the rel
Am 22.12.2012 19:13, schrieb Andrei Alexandrescu:
> On 12/22/12 12:53 PM, Sönke Ludwig wrote:
>> Am 22.12.2012 17:49, schrieb Sönke Ludwig:
>>>
>>> Continuing the thought of screen real estate - shouldn't these sections
>>> better be at the _bottom_ of
>>> the page? After all they are just noise f
Am 22.12.2012 19:20, schrieb Jacob Carlborg:
> On Saturday, 22 December 2012 at 17:54:29 UTC, Sönke Ludwig wrote:
>
>> In the latest upload a number of items is addressed:
>> - vertical margins at the top
>> - redundant column headers
>> - +/- signs for the package tree
>> - jumps to line numb
On 12/22/12 12:53 PM, Sönke Ludwig wrote:
Am 22.12.2012 17:49, schrieb Sönke Ludwig:
Continuing the thought of screen real estate - shouldn't these sections better
be at the _bottom_ of
the page? After all they are just noise for the typical reader and since the
pages are not as long
anymore,
On Saturday, 22 December 2012 at 08:47:44 UTC, Jonathan M Davis
wrote:
Pretty much every time that this issue comes up, people are
surprised by the
fact that private symbols aren't hidden and pretty much no one
wants them to
be in overload sets. I think that you're the only one that I've
seen p
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
On 12/13/2012 4:17 PM, David Nadlinger wrote:
1. How much work would it be for the guys at Remedy Games to
convert their
codebase from [] to @()?
I don't know. All I know is it's a lot of code.
You should ask. It's really cra
On Saturday, December 22, 2012 20:11:25 Rob T wrote:
> I had no idea this was going on. If "private" symbols are not
> really private then they shouldn't be called private because that
> is very misleading and can lead to subtle mistakes that will be
> difficult to understand and avoid.
>
> When I
Am 22.12.2012 19:56, schrieb Andrei Alexandrescu:
> On 12/22/12 12:53 PM, Sönke Ludwig wrote:
>> Am 22.12.2012 17:49, schrieb Sönke Ludwig:
>>>
>>> Continuing the thought of screen real estate - shouldn't these sections
>>> better be at the _bottom_ of
>>> the page? After all they are just noise f
On Friday, 21 December 2012 at 18:31:48 UTC, Sönke Ludwig wrote:
Am 21.12.2012 18:05, schrieb Andrei Alexandrescu:
(...)
The cheat sheet in std.algorithm is unnecessary (though I
liked the brief examples), but there's a
lot of value in the symbols grouped by category (searching,
comparison, .
On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg wrote:
On 2012-12-21 18:05, Andrei Alexandrescu wrote:
s/remove/integrate/
s/ugly/awesome/
It's ugly that they are manually created. Over 300 lines of
comments that the doc generator should be doing automatically.
I would say that
On 12/22/12 5:10 PM, foobar wrote:
On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg wrote:
On 2012-12-21 18:05, Andrei Alexandrescu wrote:
s/remove/integrate/
s/ugly/awesome/
It's ugly that they are manually created. Over 300 lines of comments
that the doc generator should be doin
On Saturday, 22 December 2012 at 20:24:54 UTC, Jonathan M Davis
wrote:
They're private in the same way that they're private in C++.
They're
inaccessible (i.e. can't be called), but they're not actually
hidden.
Accessibility is only taken into account after overloading has
been sorted
out. About
I don't know if this has been mentioned yet, but some modules
have a link to the source while others do not. I suppose that's a
problem with the documentation itself not including a link. I'm
just mentioning this in case it has something to do with the
formatting.
--rt
On 22 December 2012 19:32, Leandro Lucarella <
leandro.lucare...@sociomantic.com> wrote:
> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
>
>> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>>
>>> 1. How much work would it be for the guys at Remedy Games to convert
>>> their
>>>
On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Buclaw wrote:
On 22 December 2012 19:32, Leandro Lucarella <
leandro.lucare...@sociomantic.com> wrote:
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright
wrote:
On 12/13/2012 4:17 PM, David Nadlinger wrote:
1. How much work would i
On 23 December 2012 00:11, ixid wrote:
> On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Buclaw wrote:
>
>> On 22 December 2012 19:32, Leandro Lucarella <
>> leandro.lucarella@sociomantic.**com >
>> wrote:
>>
>> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
>>>
>>> On 12
On 12/23/2012 01:29 AM, Iain Buclaw wrote:
On 23 December 2012 00:11, ixid mailto:nuacco...@gmail.com>> wrote:
...
Surely someone like Walter or yourself (I am not suggesting that
it's your responsibility) could have written a reliable find and
replace for the other attribute syntax
On Saturday, 22 December 2012 at 16:41:15 UTC, Rainer Schuetze
wrote:
Could be this one:
https://github.com/D-Programming-Language/dmd/pull/1315
dmd might also add some library paths, try -v to see whether
they conflict with your manually specified paths.
Thanks for the tip. Adding a sc.in
On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
Pretty much every time that this issue comes up, people are surprised by the
fact that private symbols aren't hidden and pretty much no one wants them to
be in overload sets.
This has been discussed before, and the same people wanted private funct
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void foo(float);
}
void bar()
{
S s;
s.foo(1.0f);
}
On 12/22/2012 6:35 PM, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void foo(fl
On Saturday, December 22, 2012 18:35:47 Walter Bright wrote:
> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
> > I think this is a fallacious argument because it concludes that apples
> > should be peeled because oranges should.
>
> Given, in C++:
>
> struct S
> {
>public:
> void fo
On 12/21/2012 11:19 PM, Jonathan M Davis wrote:
but generally the worst that
they'll do is create slight overhead because of the cost of default
initializing them.
This is not an issue. An optimization called "dead assignment elimination" has
been in compilers since the 1980's, including dmd.
On 12/22/2012 1:04 AM, Jonathan M Davis wrote:
Walter has completely convinced me with regards to how bad an idea
compiler warnings are.
Wow!
On 12/22/12 9:29 PM, Walter Bright wrote:
On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
Pretty much every time that this issue comes up, people are surprised
by the
fact that private symbols aren't hidden and pretty much no one wants
them to
be in overload sets.
This has been discussed befor
On Sunday, 23 December 2012 at 02:35:46 UTC, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes
that apples should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
privat
On Sunday, 23 December 2012 at 04:43:27 UTC, Rob T wrote:
For dlopen() the default behavior is RTLD_LOCAL, which makes
all symbols from loaded libs private to their respective libs.
This is the default behavior to ensure predictable execution
behaviors, and it's the same default behavior that m
On 12/23/2012 03:35 AM, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void foo(f
On Sunday, December 23, 2012 05:56:07 Timon Gehr wrote:
> structs and classes are utterly irrelevant at this point of the discussion.
That's mostly true, but UFCS probably makes it so that structs and classes are
in the same boat as free functions in modules are. Without UFCS, it's a
relatively
On Monday, December 10, 2012 16:29:14 H. S. Teoh wrote:
> I fleshed out the wiki page on contributing to D, based on what I know:
>
> http://wiki.dlang.org/Get_involved
>
> But I think it needs at least another pair of eyes from other D
> contributors to add missing details or fix blatant e
Leandro Lucarella wrote:
> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
>> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>>> 1. How much work would it be for the guys at Remedy Games to
>>> convert their
>>> codebase from [] to @()?
>>
>> I don't know. All I know is it's a lot
Am 23.12.2012 00:11, schrieb Rob T:
> I don't know if this has been mentioned yet, but some modules have a link to
> the source while others
> do not. I suppose that's a problem with the documentation itself not
> including a link. I'm just
> mentioning this in case it has something to do with th
54 matches
Mail list logo
