On Sunday, 18 August 2013 at 01:52:50 UTC, Timothee Cour wrote:
Is there any way to get the enclosing function as symbol ?
I'd like something like that:
alternative names would be:
__function__
__context__
auto fun(alias caller=__function__)(){
//caller represents fun1!double
return Re
On Sunday, 18 August 2013 at 01:52:50 UTC, Timothee Cour wrote:
Is there any way to get the enclosing function as symbol ?
I'd like something like that:
alternative names would be:
__function__
__context__
auto fun(alias caller=__function__)(){
//caller represents fun1!double
return Re
On Sunday, 18 August 2013 at 00:17:22 UTC, captaindet wrote:
On 2013-08-17 14:36, Jesse Phillips wrote:
Third you've declared a variable, bar, which will store your
enumerated value, 4. Variables are not compile time, even if
the
value stored came from a compile time known value.
yep, it com
Is there any way to get the enclosing function as symbol ?
I'd like something like that:
alternative names would be:
__function__
__context__
auto fun(alias caller=__function__)(){
//caller represents fun1!double
return ReturnType!caller.init;
}
T fun1(T)(T x){
assert(__function__.str
that's not DRY: in my use case, a group of functions use certain imports,
it would be annoying and not DRY to do that. What I suggest (allowing {}
grouping at module scope) seems simple and intuitive; any reason it can't
be done?
On Sat, Aug 17, 2013 at 6:16 PM, Joseph Rushton Wakeling <
joseph.w
On Saturday, 17 August 2013 at 22:30:14 UTC, Timothee Cour wrote:
Is there a way to achieve this:
module foo;
{
import bar;
void fun1(){bar.barfun();}
void fun2(bar.BarType a){}
}
// now bar is not in scope anymore.
void fun3(){}
This would reduce name clashes conflicts, ease refact
H. S. Teoh:
Unfortunately, it's not within my control. It's the mailing
list to NNTP
gateway that has a bug where message IDs are sometimes
rewritten when
they're not supposed to be. I suggest you should pester the
listmaster
instead, that way, we'll get a solution that works for
everybody, n
On Sun, Aug 18, 2013 at 01:24:12AM +0200, bearophile wrote:
> H. S. Teoh:
>
> Most of your answer posts break threads. I suggest you to try to
> find ways to avoid that.
[...]
Unfortunately, it's not within my control. It's the mailing list to NNTP
gateway that has a bug where message IDs are som
On 2013-08-17 14:36, Jesse Phillips wrote:
Third you've declared a variable, bar, which will store your
enumerated value, 4. Variables are not compile time, even if the
value stored came from a compile time known value.
yep, it completely escaped me that these are 'normal' variables. and i have
On Sat, Aug 17, 2013 at 3:36 PM, H. S. Teoh wrote:
> On Sat, Aug 17, 2013 at 03:29:56PM -0700, Timothee Cour wrote:
> [...]
> > Related question:
> >
> > Why isn't the following allowed:
> >
> > void fun(){
> > // code without version=A
> > version=A;
> > // code with version=A
> > vesio
Additionally, is there a way to get:
* the absolute path of __FILE__ at the time the file was compiled (the
compiler knows it)
* the current directory in which the compiler compiled that file
On Sat, Aug 17, 2013 at 1:26 PM, Timothee Cour wrote:
> I'd like to redefine 'void _d_assertm(ModuleInf
thanks.
That's a bit clunky though, so it's unlikely to be used. Not sure what it
would take to make the grammar allow it.
On Sat, Aug 17, 2013 at 4:23 PM, bearophile wrote:
> Timothee Cour:
>
>
> Is there a way to achieve this:
>>
>>
>> module foo;
>>
>> {
>> import bar;
>> void fun1(){ba
On Sat, Aug 17, 2013 at 4:24 PM, bearophile wrote:
> H. S. Teoh:
>
> Most of your answer posts break threads. I suggest you to try to find ways
> to avoid that.
>
This issue keeps reappearing and people keep complaining; it's not his
fault, the problem is with the forum.dlang.org and that should
H. S. Teoh:
Most of your answer posts break threads. I suggest you to try to
find ways to avoid that.
Bye,
bearophile
Timothee Cour:
Is there a way to achieve this:
module foo;
{
import bar;
void fun1(){bar.barfun();}
void fun2(bar.BarType a){}
}
// now bar is not in scope anymore.
Using a struct as namespace:
struct Foo {
import std.stdio;
static void bar(int x) { x.writeln; }
}
alias bar =
On Sat, Aug 17, 2013 at 03:29:56PM -0700, Timothee Cour wrote:
[...]
> Related question:
>
> Why isn't the following allowed:
>
> void fun(){
> // code without version=A
> version=A;
> // code with version=A
> vesion(none):
> //code versioned out
> }
>
> I understand the grammar does
Is there a way to achieve this:
module foo;
{
import bar;
void fun1(){bar.barfun();}
void fun2(bar.BarType a){}
}
// now bar is not in scope anymore.
void fun3(){}
This would reduce name clashes conflicts, ease refactorings and in general
make code a bit cleaner.
Related question:
W
Excellent discovery !
I'd like to redefine 'void _d_assertm(ModuleInfo* m, uint line){...}' to
print more informative message with full path to module; right now m.name just
shows module name.
Is the only way to manually search through include paths until it is found
? That seems silly because the compiler knows it alr
On Saturday, 17 August 2013 at 05:22:53 UTC, captaindet wrote:
import std.stdio;
enum Test{
test2 = 2,
test4 = 4
}
Enumeration.
enum foo = Test.test2;
Manifest Const
Test bar = Test.test4;
Runtime variable.
Enum is being abused. In the first case you are declaring an
On Saturday, 10 August 2013 at 15:12:39 UTC, Ali Çehreli wrote:
On 08/10/2013 08:04 AM, JR wrote:
This project made it very simple for me:
https://github.com/carlor/dlang-workspace
My belated thanks; this worked great.
Oh, i've found that that can be resolved by select().
Thanks.
Hello guys!
void connect(Address to);
Establish a connection. If the socket is blocking, connect waits
for the connection to be made. If the socket is nonblocking,
connect returns immediately and the connection attempt is still
in progress.
How can i obtain information about progress when s
17-Aug-2013 12:53, Timothee Cour пишет:
adding an overload would increases likelihood for bugs but could be
possible. The same holds for getopt.
Another question:
the documentation for formattedRead is quite sparse, how does it explain
the following behavior:
string s="a1 a2 a3";
string a
adding an overload would increases likelihood for bugs but could be
possible. The same holds for getopt.
Another question:
the documentation for formattedRead is quite sparse, how does it explain
the following behavior:
string s="a1 a2 a3";
string a,b;
uint n=formattedRead(s,"%s %s",&a,&b);
On 2013-08-17 01:51, captaindet wrote:
my understanding was that enums are all compile time entities that
are just copied around. at compile time. a named enum type should
make no difference.
oh i see now, naming them is just creating a disguise for the base type. then
they can become compile-
On 2013-08-17 01:51, captaindet wrote:
named enums become runtime objects
-> named enums become runtime *only* objects
27 matches
Mail list logo
