Re: Why is there no named parameter support?
On Tue, 09 Jun 2015 09:50:15 +, Marc Schütz wrote:
On Tuesday, 9 June 2015 at 05:39:06 UTC, Timothee Cour wrote:
I'd be very interested in reading more about those reasons beyond FUD.
The arguments in favor have been repeated many times over, and the only
argument against that I've heard ('overloading and named arguments do
not play well together') doesn't seem valid, given the precedent in
nim.
The only problems I can think of is if they affect name mangling,
because then you would need to specify the names on each call. As long
as they are optional syntax sugar, like in ketmar's POC implementation,
they will probably work well.
they have to affect mangling for templates, though, if we want the
ability to forward calls as is in templates. but i believe that this
can be dealt with later -- i.e. in another PR.
signature.asc
Description: PGP signature
Re: Why is there no named parameter support?
On Tuesday, 9 June 2015 at 05:39:06 UTC, Timothee Cour wrote:
I'd be very interested in reading more about those reasons
beyond FUD.
The arguments in favor have been repeated many times over, and
the only
argument against that I've heard ('overloading and named
arguments do not
play well together') doesn't seem valid, given the precedent in
nim.
The only problems I can think of is if they affect name mangling,
because then you would need to specify the names on each call. As
long as they are optional syntax sugar, like in ketmar's POC
implementation, they will probably work well.
Re: using D without GC
On Monday, 8 June 2015 at 20:11:31 UTC, Oleg B wrote: On Monday, 8 June 2015 at 13:37:40 UTC, Marc Schütz wrote: On Monday, 8 June 2015 at 12:24:56 UTC, Oleg B wrote: I guess you should follow andrei's post about new allocators! Can you get link to this post? These are some of his posts: http://forum.dlang.org/thread/mku0n4$s35$1...@digitalmars.com http://forum.dlang.org/thread/mkl1eh$1mdl$2...@digitalmars.com http://forum.dlang.org/thread/mjig8h$2rgi$1...@digitalmars.com http://forum.dlang.org/thread/mjdcep$11ri$1...@digitalmars.com http://forum.dlang.org/thread/mj3p2j$2qva$1...@digitalmars.com http://forum.dlang.org/thread/mir0lg$2l74$1...@digitalmars.com http://forum.dlang.org/thread/min9k8$9r9$1...@digitalmars.com Thank! Can you say how long wait (on average) to experimental modules will cease be an experimental and will be part of phobos? At next release or it unknown? Don't know in general. This one isn't even in Phobos yet, but OTOH it is a feature that's very much in demand, so the process might be sped up. Maybe it could even go directly to std.allocator instead of std.experimental.allocator...
Re: Why is there no named parameter support?
On Mon, 08 Jun 2015 20:32:56 -0700, Jonathan M Davis via Digitalmars-d-learn wrote: is, but personally, I think that named arguments are a terrible idea in general, so I'm not about to try and support a position that tries to bring them into D. it's a perfect thing. i always hate that Flag thingy, and with named arguments i finally got rid of it. void foo (bool skipSomething); foo(skipSomething:true); no more additional imports and additional types for the simple things. besides, i like `createWindow(x:10, y:10, width:20, height:40)` more than `createWindow(10, 10, 20, 40)`. sure, one can do all kind of acrobatics to emulate that, but why? ah, another thing that Walter never used so he doesn't see it as a good thing to have. signature.asc Description: PGP signature
Re: Why is there no named parameter support?
On Mon, 08 Jun 2015 22:58:10 -0700, Jonathan M Davis via Digitalmars-d-learn wrote: Personally, I hate how named arguments affect the API (e.g. the names of the parameters suddenly become part of the API), and for the most part, the only times that they're worth much is when you have so many function parameters that you should be creating structs to hold those values anyway. I don't want them in the language, and I'm very glad that Walter is against them, so I didn't feel the need to try and remember all he said about why they were a bad idea. the funny thing is that named arguments can coexist with unnamed arguments peacefully. signature.asc Description: PGP signature
Re: setjmp / longjmp
On 27/04/2015 10:41, ketmar wrote: snip i believe this has something to do with exception frames. but it needs further investigation. What is an exception frame, exactly? Moreover, are these frames applicable even in sections of code where no throwing or catching of exceptions takes place? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: setjmp / longjmp
On Tue, 09 Jun 2015 11:57:03 +0100, Stewart Gordon wrote: On 27/04/2015 10:41, ketmar wrote: snip i believe this has something to do with exception frames. but it needs further investigation. What is an exception frame, exactly? to correctly do unwinding and other interesting things exception handler should do, compiler must establish special hidden structures in the form of single-linked list, so runtime can traverse it backwards if it needs to unwind the stack (i.e. calling destructors for structs, for example). Moreover, are these frames applicable even in sections of code where no throwing or catching of exceptions takes place? exception can be thrown by function that is called from your code. compiler needs to setup structures to correctly unwind the stack in this case. if nothing will throw, that setup cost as almost zero and can be ignored. but playing games with stack can lead to corruption of such structures (runtime doesn't know that stack was changed, and it can't update it's internal data structures accordingly). this may be harmless, or may lead to crash, or may lead to memory corruption without immediate crashing, or... effects are unpredictable. tldr; don't use setjmp/longjmp in the language with exceptions, unless you can describe it's runtime internals and exception handling down to assembler code when you're awaken at night completely drunk. ;-) signature.asc Description: PGP signature
rt_finalize question
Hello. In object.di rt_finalize calls for class objects in
destroy func.
I not found it in dmd source on github and not found in druntime
sources.
I think rt_finalize must call dtors for object and base classes,
but I think that's not all. Or if it all has it code logic
problems?
void myDestroy(T)( T obj ) if( is( T == class ) )
{
mixin( callDtor!( obj.stringof,
TypeTuple!(T,BaseClassesTuple!T) ) );
}
string callDtor( string name, BCT... )() @property
{
import std.string;
static if( BCT.length == 1 ) return ; // Object has no dtor
else
return format( %s.%s.__dtor();\n, name,
BCT[0].stringof.split(.)[$-1] ) ~
callDtor!(name, BCT[1..$]);
}
function callDtor generate string like this
obj.C.__dtor();
obj.B.__dtor();
obj.A.__dtor();
for class model
class A{}
class B : A {}
class C : B {}
I want understand why destroy for class objects call extern(C)
function rt_finalize (not pure, with gc, can except), and how it
works (rt_finalize gets void*).
Re: rt_finalize question
I found it https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L1350 Creates new questions. Why it's extern(C)? What must do collectHandler function? If I understand correctly monitor relates to multithreading control (Mutex?).
Re: Is it possible to add items to the arrays and hashes at compile time?
On Sunday, 7 June 2015 at 15:20:17 UTC, Ali Çehreli wrote:
/* Some function that generates an AA */
Thanks. Beautiful code, but I want a little more :)
/* Some function that generates an AA */
int[][int][int] initHash(int i)
{
/* It is nice to see that this function is not called at run
time */
if (!__ctfe) {
import std.stdio;
writefln(%s is called at run time, __FUNCTION__);
}
return [i : [ i : [i, i] ] ];
}
/* Question: Is there a function to merge two AAs? */
int[][int][int] merge(Hash)(Hash[] hashes...)
{
/* It is nice to see that this function is not called at run
time */
if (!__ctfe) {
import std.stdio;
writefln(%s is called at run time, __FUNCTION__);
}
int[][int][int] result;
foreach (hash; hashes) {
foreach (key, value; hash) {
result[key] = value;
}
}
return result;
}
/* These three are generated at compile time */
enum firstPart = initHash(1);
enum secondPart = initHash(2);
enum int[][int][int] ctHash = merge(firstPart, secondPart);
void main()
{
import std.stdio;
static if (!(4 in ctHash)) {{
// ...
}}
ctHash[4][4] ~= [4, 4]; // I want this to work at compile time :)
// Possible?
static if (!!(4 in ctHash)) {{
// ...
}}
}
Re: Is it possible to add items to the arrays and hashes at compile time?
On Wednesday, 10 June 2015 at 03:38:32 UTC, Ali Çehreli wrote:
The way I understand it and the way it makes sense to me, :)
variables that are generated at compile time can be initialized
only once. It is not possible after initialization. However,
the initialization of the variable can be as complex as needed:
Thanks. It turns out I can do this:
import std.stdio;
auto merge(Hashes)(Hashes[] hashes...) {
int[][int][int] result;
foreach (hash; hashes) {
foreach (key, value; hash) {
result[key] = value;
}
}
return result;
}
enum firstPart = [1 : [ 1 : [1, 1] ] ];
enum secondPart = [2 : [ 2 : [2, 2] ] ];
int[][int][int] init_ctHash(int i) {
auto result = merge(firstPart, secondPart);
result[i] = [ i : [i, i] ];
return result;
}
void main() {
enum int[][int][int] ctHash = init_ctHash(5);
enum t = merge(ctHash, init_ctHash(6));
writeln(t);
}
But I can not do so:
enum int[][int][int] ctHash = init_ctHash(5);
ctHash = merge(ctHash, init_ctHash(6));
I have a question: why variables may not be initialized more than
once? Why can't they to resave at compile time?
Re: Is it possible to add items to the arrays and hashes at compile time?
On 06/09/2015 06:53 PM, Dennis Ritchie wrote:
ctHash[4][4] ~= [4, 4]; // I want this to work at compile time :)
// Possible?
It is possible but not exactly as you wrote. In other words, it is not
as flexible.
The way I understand it and the way it makes sense to me, :) variables
that are generated at compile time can be initialized only once. It is
not possible after initialization. However, the initialization of the
variable can be as complex as needed:
enum int[][int][int] ctHash = init_ctHash();
int[][int][int] init_ctHash(){
auto result = merge(firstPart, secondPart);
result[4] = [4 : [4, 4 ]];
return result;
}
(I couldn't get ctHash[4][4] to work; so I changed the code like above.)
Ali
