I've been playing with string mixins, and they are very powerful.

One thing I can't figure out is what exactly can and cannot be evaluated at compile time.

For example:

----
char[] myFunc1() {
	return "int a = 1;";
}

char[] myFunc2() {
	char[] myFunc3() {
		return "int b = 2;";
	}
	return myFunc3();
}

void main() {
	mixin(myFunc1());
	mixin(myFunc2());
}
----

myFunc1() can be used as a string mixin.
myFunc2() can't be.

I'm sure there are other things that I'll run into, but I figure there is some simple set of rules of what can and can't be used as a string mixin.

Travis Boucher wrote:
> I've been playing with string mixins, and they are very powerful.
> 
> One thing I can't figure out is what exactly can and cannot be evaluated at compile time.
> 
> For example:
> 
> ----
> char[] myFunc1() {
>     return "int a = 1;";
> }
> 
> char[] myFunc2() {
>     char[] myFunc3() {
>         return "int b = 2;";
>     }
>     return myFunc3();
> }
> 
> void main() {
>     mixin(myFunc1());
>     mixin(myFunc2());
> }
> ----
> 
> myFunc1() can be used as a string mixin.
> myFunc2() can't be.
> 
> I'm sure there are other things that I'll run into, but I figure there is some simple set of rules of what can and can't be used as a string mixin.

Hi Travis,

I've only been 'round here for a few months myself and often find myself
in need of answers to such questions.  I believe, though, that this is the sort of question that the group prefers to have asked on D.learn.
That's also a better forum for other newbies to find answers as well.

Regards,
Justin Johansson

On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher <boucher.travis@gmail.com> wrote:
> I've been playing with string mixins, and they are very powerful.
>
> One thing I can't figure out is what exactly can and cannot be evaluated at compile time.
>
> For example:
>
> ----
> char[] myFunc1() {
>        return "int a = 1;";
> }
>
> char[] myFunc2() {
>        char[] myFunc3() {
>                return "int b = 2;";
>        }
>        return myFunc3();
> }
>
> void main() {
>        mixin(myFunc1());
>        mixin(myFunc2());
> }
> ----
>
> myFunc1() can be used as a string mixin.
> myFunc2() can't be.
>
> I'm sure there are other things that I'll run into, but I figure there is some simple set of rules of what can and can't be used as a string mixin.

Unfortunately there aren't any easy rules to go by.  If it doesn't work CTFE, and a bug hasn't already been filed, then you could file a bug, especially if you find the problem blocking your progress. However, at this point there are plenty of things that don't work that are known and being targeted by Don already.  So a flood of "this and that don't work in CTFE" bug reports may not be so useful just yet.

Anyway, just be thankful that it now at least tells you what can't be evaluated.  That's a vast improvement over the old days when the compiler would just give a generic error message about CTFE and leave you guessing about which line it didn't like!

--bb

Bill Baxter wrote:
> On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher
> <boucher.travis@gmail.com> wrote:
>> I've been playing with string mixins, and they are very powerful.
>>
>> One thing I can't figure out is what exactly can and cannot be evaluated at
>> compile time.
>>
>> For example:
>>
>> ----
>> char[] myFunc1() {
>>        return "int a = 1;";
>> }
>>
>> char[] myFunc2() {
>>        char[] myFunc3() {
>>                return "int b = 2;";
>>        }
>>        return myFunc3();
>> }
>>
>> void main() {
>>        mixin(myFunc1());
>>        mixin(myFunc2());
>> }
>> ----
>>
>> myFunc1() can be used as a string mixin.
>> myFunc2() can't be.
>>
>> I'm sure there are other things that I'll run into, but I figure there is
>> some simple set of rules of what can and can't be used as a string mixin.
> 
> Unfortunately there aren't any easy rules to go by.  If it doesn't
> work CTFE, and a bug hasn't already been filed, then you could file a
> bug, especially if you find the problem blocking your progress.
> However, at this point there are plenty of things that don't work that
> are known and being targeted by Don already.  So a flood of "this and
> that don't work in CTFE" bug reports may not be so useful just yet.
> 
> Anyway, just be thankful that it now at least tells you what can't be
> evaluated.  That's a vast improvement over the old days when the
> compiler would just give a generic error message about CTFE and leave
> you guessing about which line it didn't like!
> 
> --bb

Don responded in D.learn.  The examples above should work on recent (>=1.047) DMD, I happen to be using gdc with 1.020.  Right now I am just seeing how far I can push it and how weird I can make code that works.

On Mon, Nov 16, 2009 at 8:44 PM, Travis Boucher <boucher.travis@gmail.com> wrote:
> Bill Baxter wrote:
>>
>> On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher <boucher.travis@gmail.com> wrote:
>>>
>>> I've been playing with string mixins, and they are very powerful.
>>>
>>> One thing I can't figure out is what exactly can and cannot be evaluated
>>> at
>>> compile time.
>>>
>>> For example:
>>>
>>> ----
>>> char[] myFunc1() {
>>>       return "int a = 1;";
>>> }
>>>
>>> char[] myFunc2() {
>>>       char[] myFunc3() {
>>>               return "int b = 2;";
>>>       }
>>>       return myFunc3();
>>> }
>>>
>>> void main() {
>>>       mixin(myFunc1());
>>>       mixin(myFunc2());
>>> }
>>> ----
>>>
>>> myFunc1() can be used as a string mixin.
>>> myFunc2() can't be.
>>>
>>> I'm sure there are other things that I'll run into, but I figure there is some simple set of rules of what can and can't be used as a string mixin.
>>
>> Unfortunately there aren't any easy rules to go by.  If it doesn't work CTFE, and a bug hasn't already been filed, then you could file a bug, especially if you find the problem blocking your progress. However, at this point there are plenty of things that don't work that are known and being targeted by Don already.  So a flood of "this and that don't work in CTFE" bug reports may not be so useful just yet.
>>
>> Anyway, just be thankful that it now at least tells you what can't be evaluated.  That's a vast improvement over the old days when the compiler would just give a generic error message about CTFE and leave you guessing about which line it didn't like!
>>
>> --bb
>
> Don responded in D.learn.  The examples above should work on recent (>=1.047) DMD, I happen to be using gdc with 1.020.  Right now I am just seeing how far I can push it and how weird I can make code that works.

Makes more sense now.  I *thought* nested functions had been fixed to
work recently.
The list Don pointed you to is a good guideline, but still you can
expect to find other things not on that list that the compiler can't
handle.  For instance, another big category not mentioned there is C
functions.  You can't call C functions at compile time.

--bb

Travis Boucher wrote:
> Bill Baxter wrote:
>> On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher
>> <boucher.travis@gmail.com> wrote:
>>> I've been playing with string mixins, and they are very powerful.
>>>
>>> One thing I can't figure out is what exactly can and cannot be evaluated at
>>> compile time.
>>>
>>> I'm sure there are other things that I'll run into, but I figure there is
>>> some simple set of rules of what can and can't be used as a string mixin.
>>
> 
> Don responded in D.learn.  The examples above should work on recent (>=1.047) DMD, I happen to be using gdc with 1.020.  Right now I am just seeing how far I can push it and how weird I can make code that works.

Great; saw you reposted and got your answers on D.learn.
Good luck with your further D adventures on FreeBSD*!  (* if I remember correctly your intro post said that's your platform.)

Justin