Re: DIP61: Add namespaces to D
"Walter Bright" wrote in message news:ljh472$2233$1...@digitalmars.com... True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem. I think you've misunderstood me. Modules should be used for the same exact thing they currently are - organising symbols. If you want function 'foo' to be inside module 'bar' you put 'foo' inside 'bar'. Once you have the symbol layout you want, you then annotate the declarations to specify which C++ namespace they are inside, so the mangling matches. I am NOT suggesting module name and namespace mangling should be tied together. Use D modules for symbol organisation, and add a simple feature for specifying a C++ namespace when required.
Re: FYI - mo' work on std.allocator
On Sunday, 27 April 2014 at 05:43:07 UTC, Andrei Alexandrescu
wrote:
Added SbrkRegion, SimpleBlocklist, and Blocklist.
http://erdani.com/d/phobos-prerelease/std_allocator.html#.SbrkRegion
http://erdani.com/d/phobos-prerelease/std_allocator.html#.SimpleBlocklist
http://erdani.com/d/phobos-prerelease/std_allocator.html#.Blocklist
https://github.com/andralex/phobos/blob/allocator/std/allocator.d
Destruction is as always welcome. I plan to get into tracing
tomorrow morning.
Andrei
There are quite a few places where functions could be marked
pure, nothrow, @safe, or @trusted that have not been. I have a
pull request open for many of these.
I also have a feature request. I think something like this should
be added to std.allocator:
/**
* Shortcut that encapsulates a cast and a call to emplace()
* Params:
* a = the allocator to use
* args = the arguments to $(D T)'s constructor
* Returns: a pointer to an instance of $(D T).
*/
T* allocate(T, Allocator, Args...)(auto ref Allocator a, auto ref
Args args)
@trusted if (is (T == struct))
{
import std.conv : emplace;
void[] mem = a.allocate(T.sizeof);
return emplace(cast(T*) mem.ptr, args);
}
The allocate-cast-initialize pattern is incredibly common in the
code that I've written using allocators so far and I'd like it to
be in Phobos so that it does not need to be re-implemented
everywhere.
FYI - mo' work on std.allocator
Added SbrkRegion, SimpleBlocklist, and Blocklist. http://erdani.com/d/phobos-prerelease/std_allocator.html#.SbrkRegion http://erdani.com/d/phobos-prerelease/std_allocator.html#.SimpleBlocklist http://erdani.com/d/phobos-prerelease/std_allocator.html#.Blocklist https://github.com/andralex/phobos/blob/allocator/std/allocator.d Destruction is as always welcome. I plan to get into tracing tomorrow morning. Andrei
Re: Explicit default constructor for structs
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote: E.g. it could look like this (alternative a new keyword "explicit" could be introduced, but introduction of new keywords is usually avoided if possible, AFAIK): sorry for not reading the whole post and necroposting, but please, please, please vote for new keywords! please, stop suggesting obscure features that cannot be logicaly deducted! '@explicit' attribute can work fine here, and 'this(void)' is impossible to understand without carefull *studying* the documentation. and it is really easy to miss when reading the code.
Re: possible bug in std.conv.parse
ah, i see: if (radix == 10) return parse!Target(s); in Target parse(Target, Source)(ref Source s, uint radix) it cheating a little and using 'general' decimal number parser, which accepts '+' and '-'. for other bases it uses another code though, where '+' and '-' threats as digits, which leads to error. i think that it should either not accept sign in any radix, or accept always (given the resulting type is signed, of course). the later is much more logical if you'll ask me.
Re: possible bug in std.conv.parse
On Sunday, 27 April 2014 at 00:04:15 UTC, ketmar wrote:
but this is definetely bug, i think:
void main() {
import std.stdio : writeln;
import std.conv : to;
writeln(to!int("29a", 16)); // 666
writeln(to!int("+29a", 16)); // Unexpected '+' when converting
from type string base 16 to type int
//writeln(to!int("-29a", 16)); // Unexpected '-' when
converting from type string base 16 to type int
}
it compiles, but throws exceptions on last two lines with
writeln(). base 10 accepts '+' and '-' though. why other bases
aren't?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Or maybe reuse existing keywords:
extern (C++) scope N.M { void foo(); }
or
extern (C++) module interface N.M { void foo(); }
or something along those lines.. but maybe it should look a bit
ugly :)
Re: DIP61: Add namespaces to D
On 4/26/2014 4:35 PM, Dicebot wrote: Much better. And global C++ namespace will be plain extern(C++), right? Right.
Re: DIP61: Add namespaces to D
On 4/26/2014 4:59 PM, Andrei Alexandrescu wrote:
On 4/26/14, 4:32 PM, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Noice. Would the user call it with N.M.foo() or just foo()? -- Andrei
Either. The former if there is more than one foo() found by name lookup. Just
like for imports.
Re: DIP61: Add namespaces to D
On Sat, Apr 26, 2014 at 04:32:29PM -0700, Walter Bright via Digitalmars-d wrote:
> Since the namespace keyword doesn't seem to be gaining much traction,
> an alternative syntax would be:
>
> extern (C++, N.M) { void foo(); }
>
> which would be semantically equivalent to the previous:
>
> extern (C++) namespace N { namespace M { void foo(); }}
Much better! This clearly ties it to C++ compatibility, so there's no
chance of unintentional misuse in native D code. And it doesn't waste a
D keyword on C++ compatibility.
T
--
If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Re: DIP61: Add namespaces to D
On 04/27/2014 01:59 AM, Andrei Alexandrescu wrote:
On 4/26/14, 4:32 PM, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Noice. Would the user call it with N.M.foo() or just foo()? -- Andrei
foo(), N.foo() or N.M.foo(). (Name clashes may increase the required
granularity.)
Re: possible bug in std.conv.parse
On Sunday, 27 April 2014 at 00:01:21 UTC, Andrei Alexandrescu wrote: Oops. No bug. -- Andrei Nah, sorry, that was my giant mistake, I didn't actually do the math before saying "check your math" and let my brain get confused into thinking 1000 was 128, but it is actually -128 in twos complement, the high bit is set so it is negative.
Re: possible bug in std.conv.parse
On 4/26/14, 4:43 PM, Adam D. Ruppe wrote:
On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote:
this code: std.conv.parse!byte("-128") throws error: "Overflow in
integral conversion". but this is obviously not true, as signed byte
can hold such value.
Check your math... the most negative number a signed byte can hold is
-127. The most positive number it can hold is 128, but negating that
wouldn't fit in eight bits.
Oops. No bug. -- Andrei
Re: possible bug in std.conv.parse
On 4/26/14, 4:36 PM, ketmar wrote:
this code: std.conv.parse!byte("-128") throws error: "Overflow in
integral conversion". but this is obviously not true, as signed byte can
hold such value.
the question is: is it bug, or it's intended behavior to limit signed
integrals to values which can be safely abs()ed?
Bug. -- Andrei
Re: possible bug in std.conv.parse
ah, sorry, this is my own fault, there is no bug in parser. what
i'm doing is parse!byte("128") and then negating the result.
silly me.
Re: DIP61: Add namespaces to D
On 4/26/14, 4:32 PM, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Noice. Would the user call it with N.M.foo() or just foo()? -- Andrei
Re: possible bug in std.conv.parse
On 04/27/2014 01:43 AM, Adam D. Ruppe wrote:
On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote:
this code: std.conv.parse!byte("-128") throws error: "Overflow in
integral conversion". but this is obviously not true, as signed byte
can hold such value.
Check your math... the most negative number a signed byte can hold is
-127. The most positive number it can hold is 128, but negating that
wouldn't fit in eight bits.
Check your math. :o)
Re: possible bug in std.conv.parse
On Saturday, 26 April 2014 at 23:43:11 UTC, Adam D. Ruppe wrote: Check your math sorry, i should check my own math. I got it backwards, you're right.
Re: DIP61: Add namespaces to D
On 4/26/2014 3:01 PM, Timon Gehr wrote: On 04/26/2014 10:32 PM, Daniel N wrote: The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file. Andrei I would argue that this restriction is a benefit not a disadvantage, Why on earth would precluding an organisation of the binding in the file system mirroring the C++ side be a benefit? I've also been arguing that the druntime import hierarchy for imports of C system headers should match the layout of how a C user typically #include's them. I.e. we should not be trying to fix the hierarchy of C include's, and we shouldn't for C++, either.
Re: possible bug in std.conv.parse
On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote:
this code: std.conv.parse!byte("-128") throws error: "Overflow
in integral conversion". but this is obviously not true, as
signed byte can hold such value.
Check your math... the most negative number a signed byte can
hold is -127. The most positive number it can hold is 128, but
negating that wouldn't fit in eight bits.
Re: possible bug in std.conv.parse
ketmar:
this code: std.conv.parse!byte("-128") throws error: "Overflow
in integral conversion". but this is obviously not true, as
signed byte can hold such value.
the question is: is it bug, or it's intended behavior to limit
signed integrals to values which can be safely abs()ed?
This code works to me:
void main() {
import std.conv: to, parse;
auto s1 = "-128";
assert(s1.parse!byte == -128);
immutable s2 = "-128";
assert(s2.to!byte == -128);
}
What's your compiler version?
Bye,
bearophile
Re: DIP61: Add namespaces to D
On 4/26/2014 2:45 PM, Dicebot wrote: On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote: On 4/26/2014 1:06 PM, Jacob Carlborg wrote: BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ? By putting first foo in A/B.d and second foo in C/D.d Unfortunately, C++ programmers don't use namespaces in a way that corresponds to the .h file names. By forcing them to lay out their D interface files quite differently than their .h files, it puts a large burden on them.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Much better. And global C++ namespace will be plain extern(C++),
right?
Re: DIP61: Add namespaces to D
Walter Bright:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
It looks worse, so it looks better :-)
Bye,
bearophile
possible bug in std.conv.parse
this code: std.conv.parse!byte("-128") throws error: "Overflow in
integral conversion". but this is obviously not true, as signed
byte can hold such value.
the question is: is it bug, or it's intended behavior to limit
signed integrals to values which can be safely abs()ed?
Re: DIP61: Add namespaces to D
On 4/26/2014 2:58 PM, Gary Willoughby wrote: I disagree, a recent project I'm completing simply wouldn't of been possible without them. On the surface they look superfluous but in the right situation they are a very elegant solution. I'll be announcing my project soon. Cool. I'm looking forward to it!
Re: DIP60: @nogc attribute
On 04/27/2014 01:32 AM, bearophile wrote: If I am not missing some more point, what is the best solution? Before this question gets lost, I'd like to receive some kind of answer. Thank you, bearophile The front end already distinguishes dynamic and static array literals (in a limited form), this distinction should simply carry through to code generation and static array literals should be allowed in @nogc code.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:35:44 UTC, Walter Bright wrote: On 4/26/2014 2:45 PM, Dicebot wrote: On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote: On 4/26/2014 1:06 PM, Jacob Carlborg wrote: BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ? By putting first foo in A/B.d and second foo in C/D.d Unfortunately, C++ programmers don't use namespaces in a way that corresponds to the .h file names. By forcing them to lay out their D interface files quite differently than their .h files, it puts a large burden on them. Well this is only reason why I am not adamant about this and eager to compromise ;) Still, providing tool that does C++ .h to .di conversion but does idiomatic adaptation to D module system sounds like a better long-term solution which will benefit both existing D infrastructure and interests of C++ programmers.
Re: DIP60: @nogc attribute
If I am not missing some more point, what is the best solution? Before this question gets lost, I'd like to receive some kind of answer. Thank you, bearophile
Re: DIP61: Add namespaces to D
Since the namespace keyword doesn't seem to be gaining much traction, an
alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N { namespace M { void foo(); }}
Re: DIP61: Add namespaces to D
On 04/27/2014 01:11 AM, Dicebot wrote: On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote: On 04/27/2014 12:43 AM, Dicebot wrote: On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. Using named mixin templates for pure scope resolution is side effect and should be discouraged in any reasonable code. I don't really advocate using named mixin templates directly as much as just the same lookup rules. Well that wasn't clear from your comments at all, quite the contrary ;) ... Wtf? There are specific D tools designed for that from the very beginning Named mixin templates are also 'designed for scope resolution from the very beginning' if that means anything. and we should use and/or fix those. They don't fit. You simply cannot have multiple D modules per file. I don't see any problem with having lot of files. It is natural way organizing D code if you consider protection attributes that define module as minimal encapsulation unit. I don't see the point of requiring replication of the namespace structure in directories just for the sake of conflating modules and namespaces, even though #includes bear a closer resemblance in usage to imports than using directives and doing better is basically free because the required lookup semantics are already there. Why discuss anything but syntax at this point?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote: On 04/27/2014 12:43 AM, Dicebot wrote: On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. Using named mixin templates for pure scope resolution is side effect and should be discouraged in any reasonable code. I don't really advocate using named mixin templates directly as much as just the same lookup rules. Well that wasn't clear from your comments at all, quite the contrary ;) There are specific D tools designed for that from the very beginning Named mixin templates are also 'designed for scope resolution from the very beginning' if that means anything. and we should use and/or fix those. They don't fit. You simply cannot have multiple D modules per file. I don't see any problem with having lot of files. It is natural way organizing D code if you consider protection attributes that define module as minimal encapsulation unit.
Re: DIP61: Add namespaces to D
On 04/27/2014 12:43 AM, Dicebot wrote: On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. Using named mixin templates for pure scope resolution is side effect and should be discouraged in any reasonable code. I don't really advocate using named mixin templates directly as much as just the same lookup rules. There are specific D tools designed for that from the very beginning Named mixin templates are also 'designed for scope resolution from the very beginning' if that means anything. and we should use and/or fix those. They don't fit. You simply cannot have multiple D modules per file.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote:
On 4/26/2014 8:19 AM, Timon Gehr wrote:
Well, the proposed feature does not add any new capabilities
except proper
mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
That's right.
which is available today. I guess namespaces will occur in
pure D code as
sparsely as the above construction, because they are not
particularly useful.
Yeah, template mixins turned out to be a solution looking for a
problem.
template mixins are great.
Nitpick: If they could (optionally) truly inject themselves in a
scope (useful for automatically generating function overloads /
constructors) then they would be even better.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. Using named mixin templates for pure scope resolution is side effect and should be discouraged in any reasonable code. There are specific D tools designed for that from the very beginning and we should use and/or fix those.
Re: DIP61: Add namespaces to D
On 04/27/2014 12:03 AM, David Nadlinger wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
Which is all the DIP adds. I do not really understand the objections.
It adds a new language feature, which is not just used only in a rather
specific situation, but also very likely to be confused with the
eponymous feature from other languages. Just add the C++ mangling
functionality to mixin templates using a pragma/attribute and be done,
no need to add a whole new language primitive.
David
I.e.
mixin template SpareIdentifier(){
// ...
}
extern(C++) pragma(namespace) mixin SpareIdentifier foo;
Re: DIP61: Add namespaces to D
On 04/26/2014 09:56 PM, Andrei Alexandrescu wrote: I think this is not a good proposal from a "proportional response" standpoint: it squanders a keyword for a minor feature. I also think the preexisting suggestions are each wanting in various ways. That's why we should guide the discussion not in the direction of ranking existing proposals, but instead to acknowledge we have a collection of bad proposals on the table and we need to define a better one. I.e. your only objection to this is its syntax?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: Which is all the DIP adds. I do not really understand the objections. It adds a new language feature, which is not just used only in a rather specific situation, but also very likely to be confused with the eponymous feature from other languages. Just add the C++ mangling functionality to mixin templates using a pragma/attribute and be done, no need to add a whole new language primitive. David
Re: DIP61: Add namespaces to D
On 04/26/2014 10:32 PM, Daniel N wrote: The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file. Andrei I would argue that this restriction is a benefit not a disadvantage, Why on earth would precluding an organisation of the binding in the file system mirroring the C++ side be a benefit?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: Yeah, template mixins turned out to be a solution looking for a problem. I disagree, a recent project I'm completing simply wouldn't of been possible without them. On the surface they look superfluous but in the right situation they are a very elegant solution. I'll be announcing my project soon.
Re: DIP61: Add namespaces to D
On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. There is no need to add namespaces to do that, and if that's really what you want it belongs in a completely different discussion. ... Why? Every name resolution rule added is already in D. The thing we can't (easily) do is mangle C++ namespaces, so a feature that only affects mangling is perfect. i.e. We don't need namespaces in D, because modules cover that. We only need namespace mangling. Which is all the DIP adds. I do not really understand the objections.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote: On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, […] This is exactly why we shouldn't add them to the language. It complicates the language considerably (just imagine having to explain all the C++ programmers why namespaces are not what they think they are) for a slightly easier implementation of a rather niche feature. David
Re: DIP61: Add namespaces to D
On 04/26/2014 08:15 PM, Walter Bright wrote:
On 4/26/2014 5:37 AM, Timon Gehr wrote:
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo("a"));
writeln(g.foo(2));
writeln(g.foo("a"));
}
Both examples should still work if the two mixins/namespaces occur in
(possibly
different) imported modules. I think this would be in line with how
lookup is
generally handled in D. (Note that I am not suggesting to make namespaces
extensible, but rather to make them overloadable.) How do you think
about this?
Yes, that's how I anticipate it working.
Nice.
That's just following existing rules.
The example with the mixins does not actually compile. I have filed this:
https://issues.dlang.org/show_bug.cgi?id=12659
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:52:41 UTC, Walter Bright wrote: On 4/26/2014 11:30 AM, Dicebot wrote: Compromise - consider namespace definition from extern(C++) during name resolution. But still keep actual feature tied to "extern(C++)" to keep its use case clear. I mentioned something similar in a previous reply to you. Hope that means we can reach a consensus. Well this corrected version shifts my negative attitude to just "I don't like it" from "I tremble in despair reading it" :) In that sense, it is a breakthrough! I like Andrei's proposal much-much more though. There needs to be a good tool to interface to C++ namespaces, no doubt. But it should not impact pure D code and it does not need to follow exact C++ code style. Forcing module separation sounds awesome and can be trivially done by binding generator, i.e. dstep.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote: On 4/26/2014 1:06 PM, Jacob Carlborg wrote: BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ? By putting first foo in A/B.d and second foo in C/D.d
Re: DIP61: Add namespaces to D
On 04/26/2014 08:13 PM, Walter Bright wrote:
private mixin template Foo(){
// declarations
}
mixin Foo foo;
... I guess namespaces will occur in pure D code as
sparsely as the above construction, because they are not particularly
useful.
Yeah, template mixins turned out to be a solution looking for a problem.
I was actually referring to the exact pattern above. I.e. a
parameter-less mixin template that is mixed in immediately exactly one
time for the named scope alone. :)
Re: DIP61: Add namespaces to D
On 2014-04-26 19:13:52 +, Walter Bright said: I think that trying to be compatible with C++ templates is utter madness. But we can handle namespaces. I'd argue that templates aren't the difficult part. Having struct/class semantics ABI-compatible with C++ is the hard part (constructors, destructors, exceptions). Once you have that, the difference between vector_of_int and vector just becomes mangling. Same thing for template functions. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 20:07:25 UTC, Andrei Alexandrescu wrote: Yah, that's why something along the lines of extern(C++) module facebook.folly; comes to mind. Following such a module declaration, stuff inside of it is considered inside C++ namespace facebook::folly. The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file. Andrei I would argue that this restriction is a benefit not a disadvantage, one would anyway likely use a tool such as DSTEP to create the bindings. I suppose the greatest benefit would be for people which doesn't use IDE:s, but also compilation time could benefit.
Re: Compile-time memory footprint of std.algorithm
24-Apr-2014 05:12, Marco Leise пишет: Am Wed, 23 Apr 2014 21:23:17 +0400 schrieb Dmitry Olshansky : 23-Apr-2014 20:56, Daniel Murphy пишет: "Dmitry Olshansky" wrote in message news:lj7mrr$1p5s$1...@digitalmars.com... At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. Or you know, switch to D and use druntime's GC. Good point. Can't wait to see D-only codebase. Hmm. DMD doesn't use a known and tried, imprecise GC because it is a lot slower. No it doesn't. It used a precursor of D's GC and that turned out to be slow. See Walter's post. How is DMD written in D using the druntime GC going to help that ? GC is that easier to reach, every enhancement to D's GC becomes instantly available. Wanna make compiler faster - make D's runtime faster! ;) I wondered about this ever since there was talk about DDMD. I'm totally expecting compile times to multiply by 1.2 or so. Since memory management is going to stay the same with disabled GC (at least for starters), I doubt things will change radically. If they will then it'll just highlight perf problems in D's runtime that need work. -- Dmitry Olshansky
Re: DIP61: Add namespaces to D
On 4/26/2014 1:06 PM, Jacob Carlborg wrote: BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ?
Re: DIP61: Add namespaces to D
On 2014-04-26 09:31:51 +, Walter Bright said: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. ... As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. My opinion is that one shouldn't use namespaces in D. But I do like this namespace concept. It sends the following message: you're welcome to use a namespace if you like -- it'll work -- but 99% of the time it'll only be some decoration in your source code that users of your API can ignore at will because everything is still available at module scope. (The 1% is when there is a name clash.) I think it's a practical thing to do to avoid fake namespace substitutes in D (look at std.datetime.Clock), even if it's a little dirty. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: DIP61: Add namespaces to D
On 4/26/2014 12:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem.
Re: DIP61: Add namespaces to D
On 4/26/14, 12:27 PM, Daniel Murphy wrote:
"Walter Bright" wrote in message news:ljgt9v$1psm$1...@digitalmars.com...
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes,
too.
We already have a feature to manage conflicts and organisation in D code
- modules! There is no need to add namespaces to do that, and if that's
really what you want it belongs in a completely different discussion.
The thing we can't (easily) do is mangle C++ namespaces, so a feature
that only affects mangling is perfect.
i.e. We don't need namespaces in D, because modules cover that. We only
need namespace mangling.
Yah, that's why something along the lines of
extern(C++) module facebook.folly;
comes to mind. Following such a module declaration, stuff inside of it
is considered inside C++ namespace facebook::folly.
The disadvantage of this is that it forces one .di file per namespace,
whereas in C++ people frequently use different namespaces within the
same file.
Andrei
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle). -- /Jacob Carlborg
Re: DIP61: Add namespaces to D
On 4/26/14, 2:31 AM, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. I'm anchoring a response to this although it refers to the ensuing conversation. I think this is not a good proposal from a "proportional response" standpoint: it squanders a keyword for a minor feature. I also think the preexisting suggestions are each wanting in various ways. That's why we should guide the discussion not in the direction of ranking existing proposals, but instead to acknowledge we have a collection of bad proposals on the table and we need to define a better one. Andrei
Re: DIP61: Add namespaces to D
"Walter Bright" wrote in message news:ljgt9v$1psm$1...@digitalmars.com...
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes,
too.
We already have a feature to manage conflicts and organisation in D code -
modules! There is no need to add namespaces to do that, and if that's
really what you want it belongs in a completely different discussion.
The thing we can't (easily) do is mangle C++ namespaces, so a feature that
only affects mangling is perfect.
i.e. We don't need namespaces in D, because modules cover that. We only
need namespace mangling.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:57 AM, Andrej Mitrovic wrote: Can I make a note about something? The C++ committee keeps adding new features to C++, libraries are probably going to start using those features. So when C++ gets feature X and D has to have link compatibility with C++, will we be forced to invent even more syntax just to be able to link with the latest C++1x**? All I can say is we have to use our best judgement on a case by case basis. I just really doubt C++ and D will be able to seamlessly interoperate because you can now match namespaces. Of course that's correct. But it turns out there's a lot of low-hanging fruit this will enable us to be compatible with. I fear like we're trying to accomplish with C++ what C++ has tried to accomplish with C, meaning it wants to become a superset and wrap another language. Shoehorning stuff into D just to make linking with C++ easier looks like the wrong approach to me. I think that trying to be compatible with C++ templates is utter madness. But we can handle namespaces.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:51:16 UTC, Walter Bright wrote: On 4/26/2014 11:21 AM, Dicebot wrote: Namespaces also don't solve any problem for that can't be already elegantly solved. There isn't any existing elegant solution to calling a C++ function in a namespace. Can I make a note about something? The C++ committee keeps adding new features to C++, libraries are probably going to start using those features. So when C++ gets feature X and D has to have link compatibility with C++, will we be forced to invent even more syntax just to be able to link with the latest C++1x**? I just really doubt C++ and D will be able to seamlessly interoperate because you can now match namespaces. That's the freakin' tip of the iceberg. There's so much more that you can't do, such as: - Use class objects by value in D - Manage memory in a reliable way across language boundaries (and in a usable way, meaning D users shouldn't have to call new/delete) - Handle exceptions being thrown across language boundaries I fear like we're trying to accomplish with C++ what C++ has tried to accomplish with C, meaning it wants to become a superset and wrap another language. Shoehorning stuff into D just to make linking with C++ easier looks like the wrong approach to me.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:21 AM, Dicebot wrote: Namespaces also don't solve any problem for that can't be already elegantly solved. There isn't any existing elegant solution to calling a C++ function in a namespace. See Mike's post. We are very reluctant to add new useful features because of implied implementation, documentation and learning overhead. Abandoning that principle to add a useless feature instead is just horrible. It has occurred to me to make namespaces only valid inside of an extern(C++) block. That at least would make it clear what it is for, and prevent casual use in D code.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:30 AM, Dicebot wrote: Compromise - consider namespace definition from extern(C++) during name resolution. But still keep actual feature tied to "extern(C++)" to keep its use case clear. I mentioned something similar in a previous reply to you. Hope that means we can reach a consensus.
Re: DIP61: Add namespaces to D
On 4/26/2014 11:17 AM, Adam D. Ruppe wrote: On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: Yeah, template mixins turned out to be a solution looking for a problem. template mixins rock, I use them for a bunch of things. I stand corrected :-)
Re: DIP61: Add namespaces to D
On 4/26/2014 4:01 AM, Mike wrote:
My search found the following proposals:
[1]
extern (C++, namespace = A.B) {}
Technically, this can work, and I was initially in favor of it. But it just
strikes me as awkward. It may be one of the first things C++ programmers wanting
to use D may have to see, and I don't think it would leave a good impression.
Worse, it implies this will work:
extern (C++, namespace = A.B) { ... declarations ... }
extern (C++, namespace = A.B) { ... more declarations ... }
Which would be very, very awkward to try to make work with D's scope lookup
rules.
[2]
pragma(cpp_namespace, "A.B")
extern(C++) void f() {}
This implies that it only affects the name mangling. There needs to be a scope
created, too.
[3]
@namespace("A")
{
@namespace("B") {}
}
I find nothing to recommend that over:
namespace A
{
namespace B { }
}
The object isn't to flagellate programmers wanting to call their existing C++
library code, which (realistically) is simply not going to be translated to D.
[4]
extern (C++) template A()
{
extern (C++) template B() {}
}
The trouble with that is C++ mangles templates differently than namespaces, and
this would make it impractical to then support calling C++ template functions
with no template arguments.
[5]
DIP61 a 'namespace' keyword
Would you be willing to summarize the merits/shortcomings of each of these in
your opinion?
Thanks for creating this list, it is very helpful.
The big problem with many proposals is they only address name mangling. The
scope lookup must be part of it, else it will not scale.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:18:39 UTC, Walter Bright wrote:
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the
thread, so you made
it again? My objections from the last thread still stand.
Mangling is all we
need, just add a pragma or attribute to add mangling and don't
tie it to other
language elements.
Having a pragma to just add mangling doesn't deal with problems
like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual
scopes, too.
Ideally - use usual D tools of disambugation. Modules, static
structs etc.
Compromise - consider namespace definition from extern(C++)
during name resolution. But still keep actual feature tied to
"extern(C++)" to keep its use case clear.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 15:19:55 UTC, Timon Gehr wrote:
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define
namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Well, the proposed feature does not add any new capabilities
except proper mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
which is available today. I guess namespaces will occur in pure
D code as sparsely as the above construction, because they are
not particularly useful.
This is side effect of an advanced D feature that is unlikely to
be used by newbies and is less tempting to use in practice
because it involves some boilerplate. Providing it as simple
stand-alone feature is akin to saying "hey, use me!".
I don't want that in D.
I would have also strongly objected to usage of template mixins
for namespace during any code review.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote: On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, though I could be surprised. Because using namespaces is considered good practice in C++. Those coming from languages with natural namespace support will see feature with same name and semantics in D code and will proceed with using it casually, resulting in lot of unidiomatic D libraries and applications out there. Namespaces are also much more familiar and simple thing to grasp compared to original D module system. Providing those will doom D modules because of path of least resistance - lack of good practices here makes situation rather bad already, no need to make it even worse. Namespaces also don't solve any problem for that can't be already elegantly solved. We are very reluctant to add new useful features because of implied implementation, documentation and learning overhead. Abandoning that principle to add a useless feature instead is just horrible.
Re: DIP61: Add namespaces to D
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the thread, so you made
it again? My objections from the last thread still stand. Mangling is all we
need, just add a pragma or attribute to add mangling and don't tie it to other
language elements.
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { int foo(); }
foo(); // how to specify which one gets called?
I.e. only addressing name mangling does not scale. Need actual scopes, too.
Re: DIP61: Add namespaces to D
On 4/26/2014 5:37 AM, Timon Gehr wrote:
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo("a"));
writeln(g.foo(2));
writeln(g.foo("a"));
}
Both examples should still work if the two mixins/namespaces occur in (possibly
different) imported modules. I think this would be in line with how lookup is
generally handled in D. (Note that I am not suggesting to make namespaces
extensible, but rather to make them overloadable.) How do you think about this?
Yes, that's how I anticipate it working. That's just following existing rules.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 18:13:00 UTC, Walter Bright wrote: Yeah, template mixins turned out to be a solution looking for a problem. template mixins rock, I use them for a bunch of things.
Re: DIP61: Add namespaces to D
On 4/26/2014 4:57 AM, Dicebot wrote: Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Why? I don't see much of any use for namespaces in pure D code, though I could be surprised.
Re: DIP61: Add namespaces to D
On 4/26/2014 8:19 AM, Timon Gehr wrote:
Well, the proposed feature does not add any new capabilities except proper
mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
That's right.
which is available today. I guess namespaces will occur in pure D code as
sparsely as the above construction, because they are not particularly useful.
Yeah, template mixins turned out to be a solution looking for a problem.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 11:57:48 UTC, Dicebot wrote: I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. I agree, please just add a way of calling C++ and not a brand new feature that will change the way D code should be written. I do not want or need namespaces in D code!
Re: DIP61: Add namespaces to D
On 4/26/14, 7:38 AM, Daniel Murphy wrote: "Walter Bright" wrote in message news:ljfue4$11dk$1...@digitalmars.com... There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. So, people didn't like the proposal last time you made the thread, so you made it again? My objections from the last thread still stand. Mangling is all we need, just add a pragma or attribute to add mangling and don't tie it to other language elements. For more details go back and read the old thread. I agree. -- Andrei
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 11:57:48 UTC, Dicebot wrote: On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. I agree. No need for a new keyword, and certainly no need to introduce new D language features. I couldn't care less what the syntax is, but please minimise impact.
Re: DIP61: Add namespaces to D
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of pure D code.
Well, the proposed feature does not add any new capabilities except
proper mangling. In pure D code
namespace foo{
// declarations
}
would be basically the same as
private mixin template Foo(){
// declarations
}
mixin Foo foo;
which is available today. I guess namespaces will occur in pure D code
as sparsely as the above construction, because they are not particularly
useful.
Re: DIP61: Add namespaces to D
Is there some reason why
extern(c++, std::printf);
is rejected?
If the purpose here is to map c++ code and we are only worried
about namespaces in the c++ context, why not just make it
identical to the c++ declaration?
A pragma to indicate the name mangling scheme since MS and GCC
use different algorithms and possibly a block element to say
everything under here is in this namespace, may
extern(c++namespace, std) {
extern(c++,printf);
extern(c++,open);
}
I know my examples in real code would be extern(c) but this is
just for example purposes.
Having both namespaces and modules available in general D code is
needless complexity IMHO.
Re: DIP60: @nogc attribute
"Jacob Carlborg" wrote in message news:ljfvec$126l$1...@digitalmars.com... That's a problem. The problem is if someone has an idea/code it wants to be merged, it's enough to convince one developer with push right to get it merged. At least these days it only happens when Walter and Andrei agree instead of just Walter merging whatever he feels like.
Re: DIP61: Add namespaces to D
"Walter Bright" wrote in message news:ljfue4$11dk$1...@digitalmars.com... There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. So, people didn't like the proposal last time you made the thread, so you made it again? My objections from the last thread still stand. Mangling is all we need, just add a pragma or attribute to add mangling and don't tie it to other language elements. For more details go back and read the old thread.
Re: DIP61: Add namespaces to D
On 04/26/2014 11:31 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions and
declarations in namespaces. Currently, there is no support in D to call
C++ functions in namespaces. The primary issue is that the name mangling
doesn't match. Need a simple and straightforward method of indicating
namespaces.
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
but it seems to me that the simplest, most straightforward approach
would be better.
...
I agree.
As more and more people are attempting to call C++ libraries from D,
this is getting to be a more and more important issue.
Looks good to me, but I think that the current limited lookup rules for
template mixins are not really good enough to accommodate for common
usage patterns of namespaces.
I think the following should both just work:
import std.stdio;
mixin template Foo(T){
T foo(T a){ return a; }
}
mixin Foo!int g;
mixin Foo!string g;
void main(){
writeln(foo(2));
writeln(foo("a"));
writeln(g.foo(2));
writeln(g.foo("a"));
}
// -
import std.stdio;
namespace g{
int foo(int a){ return a; }
}
namespace g{
string foo(string a){ return a; }
}
void main(){
writeln(foo(2));
writeln(foo("a"));
writeln(g.foo(2));
writeln(g.foo("a"));
}
Both examples should still work if the two mixins/namespaces occur in
(possibly different) imported modules. I think this would be in line
with how lookup is generally handled in D. (Note that I am not
suggesting to make namespaces extensible, but rather to make them
overloadable.) How do you think about this?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code.
Re: DIP61: Add namespaces to D
Am Sat, 26 Apr 2014 02:31:51 -0700
schrieb Walter Bright :
> http://wiki.dlang.org/DIP61
>
>
> but it seems to me that the simplest, most straightforward approach
> would be better.
>
> As more and more people are attempting to call C++ libraries from D,
> this is getting to be a more and more important issue.
As the namespace keyword only makes sense for c++ interfacing code it
could make sense to implement this as a compiler-recognized UDA:
Benefits:
* No new keyword, so absolutely no code breakage for old code
(namespace is likely used in some parser code as an identifier)
* @namespace is only available when explicitly importing core.cpp
which makes sense imho
* No new syntax / parser changes
The rest of the DIP wouldn't be affected in any way.
-
module core.cpp; //core.attribute, or any clever name
struct namespace
{
string ns;
}
-
In user code:
-
import core.cpp;
@namespace("N")
{
int foo(); int bar();
}
-
Example:
http://dpaste.dzfl.pl/4d583dac89dc
Another small nitpick:
The DIP does not restrict namespaces to C++ interfacing code.
I think we should avoid having namespaces and modules in D, this will
only confuse new users and lead to bad code. We should at least state
this in the DIP or only allow the namespace keyword in extern(C++)
blocks.
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 10:20:30 UTC, bearophile wrote: But I prefer an ugly-looking feature that will be used only to call C++ functions in namespaces, and not for general D programming. So you will not see D code that looks like C++. There is an advantage to keeping the D/C++ identifier namespaces separate, with a dedicated C++ syntax. I also don't mind having uglier C++ call syntax, if that makes it possible to visually determine if an identifier is either C/C++ or D at the call site (cpp_ns::identifier). Does the proposal resolve namespace conflicts between C++ and D? E.g. "std::" etc?
Re: DIP61: Add namespaces to D
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
There have been many proposals earlier:
http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
My search found the following proposals:
[1]
extern (C++, namespace = A.B) {}
[2]
pragma(cpp_namespace, "A.B")
extern(C++) void f() {}
[3]
@namespace("A")
{
@namespace("B") {}
}
[4]
extern (C++) template A()
{
extern (C++) template B() {}
}
[5]
DIP61 a 'namespace' keyword
Would you be willing to summarize the merits/shortcomings of each
of these in your opinion?
Mike
[1] http://forum.dlang.org/post/lhpq51$3st$1...@digitalmars.com
[2] https://issues.dlang.org/show_bug.cgi?id=7961#c6
[3] https://github.com/D-Programming-Language/dmd/pull/2767
[4] http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com
[5] http://forum.dlang.org/post/ljfue4$11dk$1...@digitalmars.com
Re: Issue 9148
Jonathan M Davis:
However, I'm not sure that treating it as weakly pure buys
us anything except in the case where we're trying to make
the outer function pure as well.
Here is a bit more realistic example of the problem, currently
this (rather common) code doesn't compile:
import std.algorithm, std.array, std.range;
int[] foo(in int[] data) pure {
auto indexes = iota(int(data.length));
return indexes.map!(i => i * data[i]).array;
}
void main() {}
Bye,
bearophile
Re: DIP61: Add namespaces to D
Walter Bright: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. In understand that in some cases it could be important to interface C++ code with D. But I prefer an ugly-looking feature that will be used only to call C++ functions in namespaces, and not for general D programming. So you will not see D code that looks like C++. Bye, bearophile
Re: DIP60: @nogc attribute
Walter Bright:
The @nogc logic is entirely contained in the front end, and is
not affected by back end logic.
Thank you for your answer and sorry for me being sometimes too
much nervous.
So the problem I was alarmed about doesn't exists.
Some time ago I have filed this ER:
https://issues.dlang.org/show_bug.cgi?id=12642
That shows this rejected code that I thought could be accepted:
__gshared int[1] data1;
int[1] bar() @nogc {
int x;
return [x];
}
void main() @nogc {
int x;
data1 = [x];
int[1] data2;
data2 = [x];
}
So that's an example of what you are talking about. DMD is
already performing some stack allocation of array literals that
the @nogc is not seeing and rejecting.
Kenji Hara has commented:
If you remove @nogc annotation, all array literals will be
allocated on stack. So this is pure front-end issue,
and may be fixed easily.
So the ER 12642 should be a wontfix, or a front-end rule should
be added to be added so all D compilers allocate those cases on
the stack.
If I am not missing some more point, what is the best solution?
Bye,
bearophile
Re: DIP61: Add namespaces to D
On 2014-04-26 11:31, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue. I don't think it's worth adding a completely new keyword for this feature. Even though many here will hate it I'll say it anyway, yet another feature that could be implemented with AST macros. There's even an example for just C++ namespaces [1]. [1] http://wiki.dlang.org/DIP50#C.2B.2B_Namespaces_.28issue_7961.29 -- /Jacob Carlborg
Re: DIP60: @nogc attribute
On 2014-04-25 16:28, bearophile wrote: This problem was underlined during this thread far before the merging of the @nogc implementation. Why have Walter & Andrei ignored the problem? What's the point of creating a DIP if you ignore the problems found in its discussion? What's the point of 338 comment posts if Walter goes on anyway with the original idea? There are some problems in the D development method that must be addressed. That's a problem. The problem is if someone has an idea/code it wants to be merged, it's enough to convince one developer with push right to get it merged. -- /Jacob Carlborg
DIP61: Add namespaces to D
http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces. There have been many proposals earlier: http://forum.dlang.org/post/lhi1lt$269h$1...@digitalmars.com but it seems to me that the simplest, most straightforward approach would be better. As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue.
Re: Issue 9148
On Sat, 26 Apr 2014 00:44:13 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Fri, 25 Apr 2014 23:26:29 -0400, Xinok wrote:
>
> > On Saturday, 26 April 2014 at 01:57:06 UTC, bearophile wrote:
> >> This is one of the largest problems left in the implementation of
> >> D purity:
> >>
> >> https://issues.dlang.org/show_bug.cgi?id=9148
> >>
> >> One example of the refused code:
> >>
> >>
> >> void foo(const int[] a) {
> >> int bar() pure {
> >> return a[0];
> >> }
> >> }
> >> void main() {}
> >>
> >>
> >> Bye,
> >> bearophile
> >
> > I think this would break the D conventions of purity. 'a' is not
> > immutable, only const, meaning one or more elements could change,
> > making 'bar' impure.
>
> It should compile. Purity in D is not the same as the more
> traditional definition of purity.
>
> For example, this compiles:
>
> int foo(int[] a) pure {return a[0];}
>
> I see no difference from the above.
It's the same, and it isn't. Your example has no access to anything
other than a, whereas in bearophile's example, bar has access to its
outer scope. So, you can have fun like
auto baz = new int[](5);
void foo(const int[] a)
{
int bar() pure
{
return a[0];
}
auto i = bar();
baz[0] = 2;
auto j = bar();
}
void main()
{
foo(baz);
}
Now, if we treat the outer scope like a mutable this pointer (which it
probably essentially is underneath the hood), then bar can probably be
weakly pure, but we have to be very careful not to consider it strongly
pure in spite of the fact that it has no explicit, mutable arguments.
Contrast that with
int foo(const int[] a) pure { return a[0]; }
which is the same as your example save for the const, and that function
_can_ be strongly pure if it's passed an immutable array (dmd doesn't
currently take strong purity that far - it only treats immutable
parameters as strongly pure, not immutable arguments to const
parameters -but there's no reason why it couldn't). Your example can't
be strongly pure either way though, since its parameter is mutable.
In any case, I think that bearophile's example is subtly different
from yours, though I think that we can make it weakly pure if we're
very careful about how we handle the outer scope. However, I'm not sure
that treating it as weakly pure buys us anything except in the case
where we're trying to make the outer function pure as well.
- Jonathan M Davis
Re: Compile-time memory footprint of std.algorithm
On 4/24/2014 7:16 AM, Iain Buclaw via Digitalmars-d wrote: On 24 April 2014 12:01, Ary Borenszweig via Digitalmars-d It wasn't IIRC. 'Twas in-house GC, no? It was with the C++ version of the original D collector.
Re: DIP60: @nogc attribute
On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer wrote: Well, @nogc is not released yet. Please tell me we don't have to avoid breaking code based on git HEAD... We've already done that before, with UDA's. So, you never know. -- /Jacob Carlborg
