On Monday, 28 April 2014 at 22:31:58 UTC, bearophile wrote:
Paulo Pinto:
Pascal expatriates like myself won't consider indexes from 1 a
design mistake. :)
What's the good of having all arrays always start from index 1
(this is different from Ada, where you can choose the indexing
range and
On Tuesday, 29 April 2014 at 06:22:34 UTC, Atash wrote:
Let's say that we have a struct `A` that contains some template
function named `fn` template-parameterized on its argument
types:
struct A {
...
void fn(A)(auto ref A a) { ... }
...
}
I cannot get a handle on `fn` as an alias when search
Let's say that we have a struct `A` that contains some template
function named `fn` template-parameterized on its argument types:
struct A {
...
void fn(A)(auto ref A a) { ... }
...
}
I cannot get a handle on `fn` as an alias when searching for
overloads of the string "fn" in `A` via
`__trait
On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote:
First off, I expect "std" to be put in core.stdcpp.std, and
then imported. So this issue would only happen if 3rd party A
and 4th party B each imported 5th party C. Yeah, it'll happen,
and it'll still work, as the import system rega
"Andrei Alexandrescu" wrote in message news:ljm83i$d6i$1...@digitalmars.com...
Thanks. Isn't it unprecedented for pragmas to introduce scopes and to be
un-ignorable? -- Andrei
(I'll assume you mean introduce scopes as in the {} syntax, not the way
Walter's proposal introduces scopes)
No, p
On Monday, 28 April 2014 at 18:36:59 UTC, Radu wrote:
I've seen vibe.d has some pretty nice features when it comes to
asynchronous I/O but does someone know of an example of a
STUN/TURN server written in it, or in plain D?
Every time I read anything related to STUN/TURN, it becomes
obvious th
On 4/28/2014 4:30 PM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad"
" wrote:
No. Even though they are the same function as far as the signatures are
concerned, they are different functions as far as the D
On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad"
" wrote:
No. Even though they are the same function as far as the
signatures are concerned, they are different functions as far
as the D type system is concerned, and hence the call is
am
Nick Sabalausky:
VB6 let you choose your starting index, too. It was rarely
useful and constantly made array-handling code a pain in the
ass. Of course, VB made pretty much everything a PITA...(I used
to work at a VB6 house. *shudder*)
(As far as I know, and I am ignorant about Julia) in Jul
On 4/28/2014 6:31 PM, bearophile wrote:
Paulo Pinto:
Pascal expatriates like myself won't consider indexes from 1 a design
mistake. :)
What's the good of having all arrays always start from index 1 (this is
different from Ada, where you can choose the indexing range and type)?
VB6 let you
Paulo Pinto:
Pascal expatriates like myself won't consider indexes from 1 a
design mistake. :)
What's the good of having all arrays always start from index 1
(this is different from Ada, where you can choose the indexing
range and type)?
Bye,
bearophile
Am 28.04.2014 22:31, schrieb bearophile:
Chris:
Especially in the scientific community Python is popular because one
can protoype very fast, test things etc. However, as the code base
grows it becomes more and more obvious that Python is too slow and
doesn't scale very well.
Julia seems to be
On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote:
I believe Steven expects things to work this way:
module bar;
extern(C++, foo) void func();
module prog;
import bar;
void main()
{
foo.func(); // Calls bar.func (or is that bar.foo.func?)
}
It would call bar.foo.func(). But y
On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote:
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ok
bar.
On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // error
foo.func(); // ok
bar.func(); // ok, uses C binding (no name mangling)
}
In this c
On 4/28/2014 6:55 AM, Byron wrote:
With the current DIP you have to combine the d/di files to merge the
extern namespaces.
No, you will not have to, for the same reason that all extern(C) declarations
don't have to be in the same module.
Also is there any plans on dealing with newing c++ m
On 4/28/2014 12:18 AM, Sergei Nosov wrote:
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Quote:
Unlike C++, namespaces in D will be 'closed' meaning that new declarations
cannot be inserted into a namespace after the closing }. C++ Argument
Depend
Chris:
Especially in the scientific community Python is popular
because one can protoype very fast, test things etc. However,
as the code base grows it becomes more and more obvious that
Python is too slow and doesn't scale very well.
Julia seems to be gaining many users, it's a language tha
My point is basically: a lot of projects / modules start out as
little helper functions, prototypes or proofs-of-concept, but
grow bigger very fast. Especially in the scientific community
Python is popular because one can protoype very fast, test things
etc. However, as the code base grows it b
On Monday, 28 April 2014 at 17:28:16 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 28 April 2014 at 16:22:47 UTC, Russel Winder via
Digitalmars-d wrote:
Their environment is one in which Python is the only
option (long
story), so they write in Python and then optimize by using
Cython on the
CPU i
On Monday, 28 April 2014 at 14:00:58 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer
wrote:
Not ok. This is like having 2 definitions for the same
function, linker will not accept that.
No. It is like having 2 matching type declarations. The
impl
On 4/28/2014 1:31 AM, "Ola Fosheim Grøstad"
" wrote:
So recompiling with updated libraries may cause failure?
No more than if you violate the ODR in C++, or if you do this entirely in D.
Ambiguities for the latter will cause compile time errors (which is a feature,
not a bug).
On Monday, 28 April 2014 at 18:18:25 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:
What features does python, as a language (syntactical
preferences aside), actually have to recommend it over D
(assuming drepl* or similar became full-featured)?
L
On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad"
" wrote:
This is close. Forgive inaccurate syntax, but I see at least these issues that
will make namespaces/module-system broken in terms of maintenance:
YEAR 2014:
framework1.d:
extern (C++, std){ void something(); }
framework2.d:
extern (C++,std){
On 4/28/2014 12:45 AM, Temtaime wrote:
I think he meant next:
A.d:
void foo();
A.cpp:
namespace A { void foo(); }
And now we has:
exnern(C++, A) void foo();
import A;
Error, A is defined twice.
On 4/28/14, 10:56 AM, Daniel Murphy wrote:
"Andrei Alexandrescu" wrote in message
news:ljm022$575$1...@digitalmars.com...
I've missed that proposal, and couldn't find browsing through your
recent posts. Could you please send a link, thanks. -- Andrei
Pretty sure you saw it.
http://forum.dla
On Monday, 28 April 2014 at 18:18:25 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:
What features does python, as a language (syntactical
preferences aside), actually have to recommend it over D
(assuming drepl* or similar became full-featured)?
L
I've seen vibe.d has some pretty nice features when it comes to
asynchronous I/O but does someone know of an example of a
STUN/TURN server written in it, or in plain D?
On Monday, 28 April 2014 at 18:07:45 UTC, John Colvin wrote:
What features does python, as a language (syntactical
preferences aside), actually have to recommend it over D
(assuming drepl* or similar became full-featured)?
Libraries.
For closures for arrays and dicts.
Tuples.
Heavy duty reflec
On Monday, 28 April 2014 at 09:41:43 UTC, Russel Winder via
Digitalmars-d wrote:
On Mon, 2014-04-28 at 09:27 +, John Colvin via
Digitalmars-d wrote:
[…]
As with all these things, YMMV; there are many large,
successful Python projects.
I think this is a crucially important thing to remembe
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-prerele
"Andrei Alexandrescu" wrote in message news:ljm022$575$1...@digitalmars.com...
I've missed that proposal, and couldn't find browsing through your recent
posts. Could you please send a link, thanks. -- Andrei
Pretty sure you saw it.
http://forum.dlang.org/post/lhjg4o$k82$1...@digitalmars.com
On Monday, 28 April 2014 at 16:22:47 UTC, Russel Winder via
Digitalmars-d wrote:
Their environment is one in which Python is the only
option (long
story), so they write in Python and then optimize by using
Cython on the
CPU intensive codes. This actually works very well for them.
Don't forget
On Mon, 28 Apr 2014 17:19:16 +0200
Andrej Mitrovic via Digitalmars-d wrote:
> On 4/28/14, Dicebot via Digitalmars-d
> wrote:
> > Yeah, it is just a random idea I have just had.
>
> I'm afraid you're 7 years too late for that patent. :P
>
> https://issues.dlang.org/show_bug.cgi?id=1297
I find
On 4/28/14, 1:15 AM, Daniel Murphy wrote:
"Walter Bright" wrote in message news:ljjmi6$16nk$1...@digitalmars.com...
Ok, I saw that, and replied to it earlier this thread.
Yes, but you seemed to miss the point.
Having a pragma to just add mangling doesn't deal with problems like:
name
On Mon, 2014-04-28 at 14:15 +, Chris via Digitalmars-d wrote:
[…]
> E.g. an algorithm for signal processing. Python is fine for
> prototyping, but if you want your algorithms to work in a real
> world app at real time, you'll have to rewrite it in C/C++, D or
> whatever. I've adopted the pol
On 4/28/14, 6:34 AM, Steven Schveighoffer wrote:
On Sun, 27 Apr 2014 01:43:08 -0400, 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#.Simp
On Saturday, 26 April 2014 at 20:16:34 UTC, Walter Bright wrote:
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
On 4/28/14, Dicebot via Digitalmars-d wrote:
> I was even going to write an objection to my own idea precisely
> quoting your comment in that thread but got too lazy :) Well,
> this stuff is really obvious, no wonders here.
I don't know, I'm reconsidering right now that maybe forcing static
impor
On Mon, 28 Apr 2014 11:29:53 -0400, Byron wrote:
On Mon, 28 Apr 2014 11:21:52 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 11:09:38 -0400, Byron wrote:
I am confused now, cross module renaming??
I was thinking this:
a.d extern(C++, std) { ... class string ... }
class string
On Mon, 28 Apr 2014 11:32:50 -0400, Dicebot wrote:
On Monday, 28 April 2014 at 14:27:19 UTC, Steven Schveighoffer wrote:
void main()
{
func(); // error
foo.func(); // ALSO error
bar.func(); // Not error, BUT it's actually calling foo::func from
C++ land!
}
I don't see any fundame
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
On Monday, 28 April 2014 at 14:27:19 UTC, Steven Schveighoffer
wrote:
void main()
{
func(); // error
foo.func(); // ALSO error
bar.func(); // Not error, BUT it's actually calling
foo::func from C++ land!
}
I don't see any fundamental issue here because you can still use
renamed impo
On Mon, 28 Apr 2014 11:21:52 -0400, Steven Schveighoffer wrote:
> On Mon, 28 Apr 2014 11:09:38 -0400, Byron wrote:
>
>> I am confused now, cross module renaming??
>>
>> I was thinking this:
>>
>> a.d extern(C++, std) { ... class string ... }
>
> class string now has two fully-qualified names.
On Monday, 28 April 2014 at 15:19:26 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/28/14, Dicebot via Digitalmars-d
wrote:
Yeah, it is just a random idea I have just had.
I'm afraid you're 7 years too late for that patent. :P
https://issues.dlang.org/show_bug.cgi?id=1297
I was even go
On Mon, 28 Apr 2014 11:09:38 -0400, Byron wrote:
I am confused now, cross module renaming??
I was thinking this:
a.d
extern(C++, std) { ... class string ... }
class string now has two fully-qualified names. a.string, and std.string
(assuming the current DIP is implemented).
b.d
import
On 4/28/14, Dicebot via Digitalmars-d wrote:
> Yeah, it is just a random idea I have just had.
I'm afraid you're 7 years too late for that patent. :P
https://issues.dlang.org/show_bug.cgi?id=1297
On Mon, 28 Apr 2014 11:05:25 -0400, Byron wrote:
On Mon, 28 Apr 2014 10:56:24 -0400, Steven Schveighoffer wrote:
Most definitely no. When the compiler builds b.d, he has no idea it's
imported from inside another namespace! We don't want #include-style
issues.
-Steve
So we would have to in
On Monday, 28 April 2014 at 14:54:17 UTC, Steven Schveighoffer
wrote:
Adding a mechanism that is possibly ugly, but that does NOT
conflict with module lookup, in order to disambiguate C++
symbols is fine.
Requiring C++ identifiers to be fully qualified with "::" would
solve that and encourage
On Mon, 28 Apr 2014 10:54:17 -0400, Steven Schveighoffer wrote:
>>>
>>> That doesn't help. foo.func() is still ambiguous. With this proposal,
>>> you have hijacked the meaning of namespace lookup. When I say x.y.z,
>>> it doesn't just mean look for symbol z in module x/y.d, it can also
>>> mean to
On Mon, 28 Apr 2014 10:56:24 -0400, Steven Schveighoffer wrote:
>
> Most definitely no. When the compiler builds b.d, he has no idea it's
> imported from inside another namespace! We don't want #include-style
> issues.
>
> -Steve
So we would have to include the entire namespace in a single d fi
On Mon, 28 Apr 2014 10:46:33 -0400, Byron wrote:
On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Would nesting imported namespaces work?
lib/package.d
public
export(C++, a) {
public import lib.b;
}
lib/b.d
export(C++, b) {
void foo();
}
main.d
i
On Mon, 28 Apr 2014 10:45:14 -0400, Steven Schveighoffer wrote:
> On Mon, 28 Apr 2014 10:37:36 -0400, Byron wrote:
>
>
>> why not import _cpp = bar; ?
>
> That doesn't help. foo.func() is still ambiguous. With this proposal,
> you have hijacked the meaning of namespace lookup. When I say x.
On Mon, 28 Apr 2014 10:50:09 -0400, Byron wrote:
On Mon, 28 Apr 2014 10:45:14 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 10:37:36 -0400, Byron wrote:
why not import _cpp = bar; ?
That doesn't help. foo.func() is still ambiguous. With this proposal,
you have hijacked the m
On Mon, 28 Apr 2014 10:37:36 -0400, Byron wrote:
why not import _cpp = bar; ?
That doesn't help. foo.func() is still ambiguous. With this proposal, you
have hijacked the meaning of namespace lookup. When I say x.y.z, it
doesn't just mean look for symbol z in module x/y.d, it can also
On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:
> http://wiki.dlang.org/DIP61
Would nesting imported namespaces work?
lib/package.d
public
export(C++, a) {
public import lib.b;
}
lib/b.d
export(C++, b) {
void foo();
}
main.d
import lib;
a.b.foo();
On Mon, 28 Apr 2014 10:27:19 -0400, Steven Schveighoffer wrote:
> On Sun, 27 Apr 2014 15:54:51 -0400, Walter Bright
> wrote:
>
>> http://wiki.dlang.org/DIP61
>
> I think there is a big problem with name lookup here.
>
> Consider this code:
>
> module foo;
>
> void func() {}
>
> module bar;
On Sun, 27 Apr 2014 15:54:51 -0400, Walter Bright
wrote:
http://wiki.dlang.org/DIP61
I think there is a big problem with name lookup here.
Consider this code:
module foo;
void func() {}
module bar;
extern(C) func();
module prog;
import foo;
import bar;
void main()
{
func(); // er
On Monday, 28 April 2014 at 14:08:56 UTC, Steven Schveighoffer
wrote:
I see now where your objection is. I think either the rule
needs to be better explained, or that it is incorrect.
I think so too, because if my undestanding is correct then it
will discourage writing libs in mixed D/C++ and
On Monday, 28 April 2014 at 13:26:51 UTC, Russel Winder via
Digitalmars-d wrote:
On Mon, 2014-04-28 at 09:43 +, Chris via Digitalmars-d
wrote:
[…]
Yeah, Python is good for fast prototyping, that's why the
scientific community uses it. However, when it comes to using
the code for real world
On Mon, 28 Apr 2014 09:24:59 -0400, Steven Schveighoffer
wrote:
On Sat, 26 Apr 2014 05:31:51 -0400, 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 c
On Mon, 28 Apr 2014 10:00:56 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer wrote:
Not ok. This is like having 2 definitions for the same function, linker
will not accept that.
No. It is like having 2 matching type declarations. The implem
On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer
wrote:
Not ok. This is like having 2 definitions for the same
function, linker will not accept that.
No. It is like having 2 matching type declarations. The
implementation is defined in the C++ source code and is
represented as on
On Monday, 28 April 2014 at 13:54:05 UTC, Steven Schveighoffer
wrote:
On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot
wrote:
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer
wrote:
And actually, this would have to be std.clock.currTime
(std.datetime.clock.currTime?)
What you are
On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot wrote:
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer wrote:
And actually, this would have to be std.clock.currTime
(std.datetime.clock.currTime?)
What you are looking for is renamed imports.
import std.datetime.clock = clock;
Wh
On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:
> http://wiki.dlang.org/DIP61
I really like this. I think it is clean simple and a better approach then
adding the namespace keyword. Plus when people come to D from C++ they
wont misuse namespace.
Since D has awesome module aliasing
On Sun, 27 Apr 2014 01:43:08 -0400, 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-prereleas
This is close. Forgive inaccurate syntax, but I see at least these
issues that will make namespaces/module-system broken in terms of
maintenance:
YEAR 2014:
framework1.d:
extern (C++, std){ void something(); }
framework2.d:
extern (C++,std){void something(); void anything();}
application
On Mon, 2014-04-28 at 09:43 +, Chris via Digitalmars-d wrote:
[…]
> Yeah, Python is good for fast prototyping, that's why the
> scientific community uses it. However, when it comes to using the
> code for real world apps, you have to rewrite it in C/C++ or D
> (or the like).
Why?
Many peop
On Sat, 26 Apr 2014 05:31:51 -0400, 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
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer
wrote:
On Mon, 28 Apr 2014 04:10:34 -0400, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Walter Bright via Digitalmars-d
wrote:
When you find yourself doing things like that, seriously
consider creating a
new
module to d
On Mon, 28 Apr 2014 04:10:34 -0400, Andrej Mitrovic via Digitalmars-d
wrote:
On 4/27/14, Walter Bright via Digitalmars-d
wrote:
When you find yourself doing things like that, seriously consider
creating a
new
module to do it, called "clock".
That's not reliable, because static imports
On Mon, 28 Apr 2014 10:45:40 +0200
Andrej Mitrovic via Digitalmars-d wrote:
> On 4/28/14, Jonathan M Davis via Digitalmars-d
> wrote:
> > It's my fault as far as std.datetime goes. I had it mostly done last
> > summer but then didn't have time to finish it, and enough has
> > changed since then
On Monday, 28 April 2014 at 07:45:20 UTC, Temtaime wrote:
I think he meant next:
A.d:
void foo();
A.cpp:
namespace A { void foo(); }
And now we has:
exnern(C++, A) void foo();
import A;
void main() {
A.foo(); // which foo will be called ? how to call d version or
c++ ?
}
This is close. F
On Monday, 28 April 2014 at 03:09:32 UTC, Trent Forkert wrote:
This may be my Linux bias talking, but I would tend to not want
to ship binaries as part of my source. The good thing about
CMake is that it can help you deal with your dependencies in a
sane way.
- Trent
[1]ftp://ftp.digitalmar
On 4/28/14, Jacob Carlborg via Digitalmars-d
wrote:
> When I started to complain about having too big modules nobody agreed.
Just join #d and issue the command:
!quote datetime
:P
On Monday, 28 April 2014 at 09:27:33 UTC, John Colvin wrote:
On Monday, 28 April 2014 at 09:10:53 UTC, Chris wrote:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:
I am following discussions about GC and some other 'critical'
improves in D language for a long time. I see a lot of
ar
On Mon, 2014-04-28 at 09:27 +, John Colvin via Digitalmars-d wrote:
[…]
> As with all these things, YMMV; there are many large, successful
> Python projects.
I think this is a crucially important thing to remember: YMMV.
This is not a black and white, D or Python. Different organization and
On Monday, 28 April 2014 at 09:10:53 UTC, Chris wrote:
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:
I am following discussions about GC and some other 'critical'
improves in D language for a long time. I see a lot of
arguments and heaps of code, that often hard to understand
(for
On 28/04/14 08:49, Walter Bright wrote:
We've known it for a long time, but nobody has done anything about it.
For example, the new package.d feature was specifically designed so that
long modules can be broken up without breaking user code. Nobody has yet
modified any Phobos code to actually d
On 28/04/14 10:14, Andrej Mitrovic via Digitalmars-d wrote:
Really? I've seen everyone complain about it from day 1.
When I started to complain about having too big modules nobody agreed.
--
/Jacob Carlborg
On Thursday, 24 April 2014 at 06:38:42 UTC, Suliman wrote:
I am following discussions about GC and some other 'critical'
improves in D language for a long time. I see a lot of
arguments and heaps of code, that often hard to understand (for
example Templates) even more complicated to use it.
I
On 4/28/14, Jonathan M Davis via Digitalmars-d
wrote:
> It's my fault as far as std.datetime goes. I had it mostly done last
> summer but then didn't have time to finish it, and enough has changed
> since then that I'm going to have to start over. And life has been
> quite hectic for me, making it
On Monday, 28 April 2014 at 06:47:08 UTC, Walter Bright wrote:
I have no idea what a type being "structural for the extern"
means.
"structural" is the wrong word. I meant that if two D frameworks
bind the same c++ library you want the two externs to be
interchangable in user code. However if
On Sun, 27 Apr 2014 23:49:41 -0700
Walter Bright via Digitalmars-d wrote:
> On 4/27/2014 11:17 PM, Jacob Carlborg wrote:
> > On 27/04/14 21:39, Walter Bright wrote:
> >
> >> std.datetime is a giant kitchen sink. This is not the best way to
> >> organize things. Using smaller modules under package
"Walter Bright" wrote in message news:ljjmi6$16nk$1...@digitalmars.com...
Ok, I saw that, and replied to it earlier this thread.
Yes, but you seemed to miss the point.
Having a pragma to just add mangling doesn't deal with problems like:
namespace N { int foo(); }
namespace M { i
On 4/28/14, Jacob Carlborg via Digitalmars-d
wrote:
> It's taken an amazingly long time for the core developers to realize
> this. I'm glad it's happened tough :)
Really? I've seen everyone complain about it from day 1.
On 4/27/14, Walter Bright via Digitalmars-d wrote:
> When you find yourself doing things like that, seriously consider creating a
> new
> module to do it, called "clock".
That's not reliable, because static imports are not enforced. It means
anyone importing a module "clock" will automatically ha
I think he meant next:
A.d:
void foo();
A.cpp:
namespace A { void foo(); }
And now we has:
exnern(C++, A) void foo();
import A;
void main() {
A.foo(); // which foo will be called ? how to call d version or
c++ ?
}
There's no linker problem because D and C++ has different name
mangling.
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Quote:
Unlike C++, namespaces in D will be 'closed' meaning that new
declarations cannot be inserted into a namespace after the
closing }. C++ Argument Dependent Lookup (aka "Koenig Lookup")
will not
90 matches
Mail list logo
