Re: output minimal .di files?
On Sun, 15 Jan 2012 03:53:05 -0800, F i L witte2...@gmail.com wrote:
Given the code, test.d:
import std.stdio;
export void test()
{
writeln(Test);
}
compiled with: # dmd -lib -H test.d
I end up with test.lib (good so far), and test.di:
import std.stdio;
export void test()
{
writeln(Test);
}
wtf? why is test() fully represented? I thought interface files where
suppose to be minimal, interface only structures (like C .h files). When
I manually cut everything down to: export void test(); everything
still works fine, so why is DMD spitting out the implementation?
I'm assuming that your goal is to build either or static or dynamic
libraries?
If that is the case than you can assume that CTFE and inlining will not
work anyways. This is an inherent limitation of libraries and not D. What
D currently does is assume that you want everything to work, and spits out
your implementation code symbol-for-symbol. The only thing I've found that
D ever strips out of DI files is unittests. I have written a patch for DMD
that strips out non-template class/function implementations with the
understanding that CTFE and inlining will no longer work. Templated
functions and classes retain their implementations, this is in line with
the way C++ operates. Unfortunately my patch isn't well tested yet so I
haven't opened the pull required to get it included into the main line DMD
code. But it's a available from my Git account
[https://lightben...@github.com/LightBender/dmd.git] if you don't mind
building DMD yourself.
--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Re: output minimal .di files?
On Monday, January 16, 2012 00:14:02 Adam Wilson wrote: I'm assuming that your goal is to build either or static or dynamic libraries? If that is the case than you can assume that CTFE and inlining will not work anyways. This is an inherent limitation of libraries and not D. What D currently does is assume that you want everything to work, and spits out your implementation code symbol-for-symbol. The only thing I've found that D ever strips out of DI files is unittests. I have written a patch for DMD that strips out non-template class/function implementations with the understanding that CTFE and inlining will no longer work. Templated functions and classes retain their implementations, this is in line with the way C++ operates. Unfortunately my patch isn't well tested yet so I haven't opened the pull required to get it included into the main line DMD code. But it's a available from my Git account [https://lightben...@github.com/LightBender/dmd.git] if you don't mind building DMD yourself. Inlining and CTFE should work just fine as long as everything that you're trying to inline or use with CTFE is in the .di file. Sure, whatever you strip out of the .di file won't work with CTFE or inlining, but inlining and CTFE should work just fine with dynamic libraries, exactly like if you had stuff in the .h file in C++. You just have to be willing to have it in the .di file. And you _still_ get the benefits of a dynamic library, since the symbols don't get duplicated between programs which share the library. It's just that you still have to recompile everything that it's in the .di file, so less can have its symbol hidden (for Windows anyway - there is no symbol hiding in shared libraries in linux). But you can definitely using inlining and CTFE with dynamic libraries. - Jonathan m Davis
std.math and std.mathspecial
import std.math;
import std.mathspecial;
import std.stdio;
void main(string[] args)
{
writeln(erf(0.5));
}
I was writing on my phone, so I couldn't add some code. And, my pc browser
won't load digitalmars.D html page, either, so I post this again here. It was
okay before... maybe server is too slow?
If I compile this code, I get this message.
D:\D\dmd2\windows\bin\mathconflict.d(7): Error: std.mathspecial.erf at
D:\D\dmd2
\windows\bin\..\..\src\phobos\std\mathspecial.d(273) conflicts with
std.math.erf
at D:\D\dmd2\windows\bin\..\..\src\phobos\std\math.d(1923)
and if I try using deprecated one...
import std.math;
import std.stdio;
void main(string[] args)
{
writeln(erf(0.5));
}
I get this.
D:\D\dmd2\windows\bin\mathconflict.d(6): Error: function std.math.erf is
deprecated
I think deprecated function should not cause conflict.
Re: OOP Windows
On 16/01/2012 00:34, DNewbie wrote: Is there a D version of this type of tutorial? https://www.relisoft.com/win32/index.htm This might be related to what you want: https://github.com/AndrejMitrovic/DWinProgramming -- Robert http://octarineparrot.com/
Re: A tutorial on D templates
On Fri, 13 Jan 2012 22:21:52 +0100, Philippe Sigaud
philippe.sig...@gmail.com wrote:
There is an 'Examples' section where I show what can be done with
templates and there I
'borrowed' some code posted here, with attribution. I already exchanged
with Andrej
Mitrovic (thanks!), but also took some code from Timon Gehr, Simen
Kjaeraas, Trass3r
and Jacob Carlborg. Guys, if any of you have a problem with that, tell
me so and I'll
take down the code of course. But if any of you could give me some
explanation (a small
paragraph or two?) about what your code does, I'll be forever grateful :)
The extended enum example does not compile, because you've removed the
unittest{} block around the the tests. I'd say the code in your document
should compile straight out of the box, to be newb-friendly.
As for an explanation:
string EnumDefAsString(T)() if (is(T == enum)) {
string result = ;
foreach (e; __traits(allMembers, T))
result ~= e ~ = T. ~ e ~ ,;
return result;
}
This piece of code iterates over all members of the passed enum T,
generating a string containing all members and their values. For
this enum:
enum bar {
a, b, c
}
the generated string looks like this (if you want to check this,
feel free to call EnumDefAsString at run-time and print its result):
a = bar.a,b = bar.b,c = bar.c
As we can see, this is a valid body for an enum. That means we can use
mixin() to generate this exact same enum. But wait - there's more:
template ExtendEnum(T, string s)
if (is(T == enum)
is(typeof({mixin(enum a{~s~});})))
{
mixin(
enum ExtendEnum {
~ EnumDefAsString!T()
~ s
~ });
}
This code concatenates the string generated from the previous function
with that passed to the function as parameter s. So with bar previously
defined, and this instantiation:
ExtendEnum!(bar, d=25)
the body of the function will look like this (after string expansion):
mixin(
enum ExtendEnum {
~ a = bar.a,b = bar.b,c = bar.c
~ d=25
~ });
concatenating those strings, we see that we have a valid enum definition:
enum ExtendEnum {a = bar.a,b = bar.b,c = bar.c,d=25}
The mixin then pastes it in, and it is compiled as regular D code.
TLDR:
This code generates an enum definition as a string, by taking all the
members of the old enum, and adding those passed in string parameter s,
and mixing it in.
Re: OOP Windows
On 1/16/12, Robert Clipsham rob...@octarineparrot.com wrote: https://github.com/AndrejMitrovic/DWinProgramming I think he's looking for an OOP approach, that code is basically C translated to D. There are some OOP libraries he can use, like DGUI or DFL. And there are some OOP wrappers for WinAPI somewhere (probably on dsource). Maybe http://pr.stewartsplace.org.uk/d/sdwf/ or http://www.dsource.org/projects/minwin. I think these two might be slightly outdated by now though.
Re: OOP Windows
Oh I thought that tutorial was about MFC/ATL, but it seems to use the regular C API. I might look into this to add it to the DWinProgramming project if it's worthwhile.
Error: template instance ... is not a template declaration, it is a function
Hey everyone, I've gotten that error before but I don't know how I removed it. I don't see what's wrong, it seems to work most of the time, but not always. I'm sure there's a reasonable explanation and my understanding of the matter lacks somewhat. What exactly does it mean? I'm trying to use parse!byte(line), and it reports that error. If I change it to to!byte(line) it works. How are the declarations different? line is a mere string in both cases. It works fine if I move it into main(). Thank you, Matej
Re: output minimal .di files?
On Mon, 16 Jan 2012 00:25:21 -0800, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday, January 16, 2012 00:14:02 Adam Wilson wrote: I'm assuming that your goal is to build either or static or dynamic libraries? If that is the case than you can assume that CTFE and inlining will not work anyways. This is an inherent limitation of libraries and not D. What D currently does is assume that you want everything to work, and spits out your implementation code symbol-for-symbol. The only thing I've found that D ever strips out of DI files is unittests. I have written a patch for DMD that strips out non-template class/function implementations with the understanding that CTFE and inlining will no longer work. Templated functions and classes retain their implementations, this is in line with the way C++ operates. Unfortunately my patch isn't well tested yet so I haven't opened the pull required to get it included into the main line DMD code. But it's a available from my Git account [https://lightben...@github.com/LightBender/dmd.git] if you don't mind building DMD yourself. Inlining and CTFE should work just fine as long as everything that you're trying to inline or use with CTFE is in the .di file. Sure, whatever you strip out of the .di file won't work with CTFE or inlining, but inlining and CTFE should work just fine with dynamic libraries, exactly like if you had stuff in the .h file in C++. You just have to be willing to have it in the .di file. And you _still_ get the benefits of a dynamic library, since the symbols don't get duplicated between programs which share the library. It's just that you still have to recompile everything that it's in the .di file, so less can have its symbol hidden (for Windows anyway - there is no symbol hiding in shared libraries in linux). But you can definitely using inlining and CTFE with dynamic libraries. - Jonathan m Davis I would say the main reason for using .h/.di files in libraries is that the library designer does not want his implementation public viewable. And in D, unlike C/C++, .di files are pretty much exclusive to the concept of libraries. I'd say that, based on how many questions are raised about .di files, almost no one expects the current behavior, I certainly didn't, hence my patch. The DI generation patch currently implements the C++ paradigm, where templated function implementations are publicly viewable, but non-templated function implementations are not. I feel that this paradigm, being the currently accepted convention, is the best path for D to take. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
std.stream.Stream.read([...]) matches both
Hi, I used Stream.read(out float) to read bytes of my stream. It worked for 2.056, but when I try to compile my code using 2.057 I get the following message: ((shared(float))) matches both: std.stream.Stream.read(out float x) and: std.stream.Stream.read(out real x) Because of threading the value must be shared... but how can I solve the double matching of the methods? Thanks in advance!
Struct initialization, implicit conversions and delegates
Hi,
I have two syntactic difficulties when initializing structs:
1)
Say I have a struct StringHash that represents the hash code of a string.
struct StringHash
{
this( string str )
{
computeHash(str);
}
void computeHash( string str )
{
hash = 0;
foreach(c;str)
{
hash ^= c;
hash *= 0x93;
}
}
bool opEquals( ref const(StringHash) s )
{
return hash == s.hash;
}
bool opEquals( string s )
{
return hash == StringHash(s).hash;
}
uint hash;
}
I would like this structure to be as transparent as possible and be able to
write things like:
StringHash sh = SomeString; // ok
struct Foo
{
StringHash name;
}
Foo foo = {
name : SomeString // Error: cannot implicitly convert expression
(SomeString) of type string to StringHash
category : HString( SomeString ); // works, but looks less nice IMO.
};
2)
It looks like I can't initialize fields of a struct with anonymous
functions or delegates (the error is not clear to me though), for example:
struct Element
{
void delegate(void) onSomething;
void delegate(void) onSomethingElse;
}
void main()
{
auto callBack = delegate void(void) { stdout.writeln(callBack); };
Element e = {
onSomething : callBack, // ok
onSomethingElse : delegate void(void) {
stdout.writeln(anonymous); } // errors (this is line 15, see below)
};
}
test.d(15): found ':' when expecting ';' following statement
test.d(16): found '}' when expecting ';' following statement
test.d(19): semicolon expected, not 'EOF'
test.d(19): found 'EOF' when expecting '}' following compound statement
Both of these little problems are not crucial, but they could bring some
very nice syntactic sugar on the API I am designing right now.
how should I fix it?
If the actual behaviors are desired i'd be interested to know the arguments
(well, i can imagine motivation for explicit conversion, but for the
delegate thing it's less clear to me).
Thanks,
Nicolas
Re: output minimal .di files?
On 16-01-2012 21:08, H. S. Teoh wrote: On Mon, Jan 16, 2012 at 11:38:15AM -0800, Adam Wilson wrote: [...] I would say the main reason for using .h/.di files in libraries is that the library designer does not want his implementation public viewable. And in D, unlike C/C++, .di files are pretty much exclusive to the concept of libraries. I'd say that, based on how many questions are raised about .di files, almost no one expects the current behavior, I certainly didn't, hence my patch. The DI generation patch currently implements the C++ paradigm, where templated function implementations are publicly viewable, but non-templated function implementations are not. I feel that this paradigm, being the currently accepted convention, is the best path for D to take. [...] But if you remove function bodies from inline-able functions, then your library loses out on potential optimization by the compiler. Besides, all your templates are still world-readable, which, depending on what your library is, may pretty much comprise your entire library anyway. To *truly* have separation of API from implementation, interface files shouldn't even have templated functions. It should list ONLY public declarations, no private members, no function bodies, no template bodies, etc.. All function bodies, including inline functions, template bodies, private members, etc., should be in a binary format readable only by the compiler. One way to implement this is to store template/inline function bodies inside the precompiled object files as extra info that the compiler loads in order to be able to expand templates/inline functions, compute the size of structs/classes (because private members are not listed in the API file), and so on. How this is feasible to implement, I can't say; some platforms may not allow arbitrary data inside object files, so the compiler may not be able to store the requisite information in them. T I... don't think the error messages from expanding raw object code would be very pleasant to read, if you used a template incorrectly... -- - Alex
Re: output minimal .di files?
On Mon, Jan 16, 2012 at 09:32:57PM +0100, Alex Rønne Petersen wrote: [...] I... don't think the error messages from expanding raw object code would be very pleasant to read, if you used a template incorrectly... [...] It doesn't have to be *executable* object code; the compiler may store extra info (perhaps as debugging data?) so that it can generate nicer error messages. But like I said, this assumes the compiler is allowed to store arbitrary data inside object files, which may not be the case on some platforms. T -- Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
Re: output minimal .di files?
On Mon, Jan 16, 2012 at 12:32:01PM -0800, Adam Wilson wrote: On Mon, 16 Jan 2012 12:08:53 -0800, H. S. Teoh hst...@quickfur.ath.cx wrote: [...] One way to implement this is to store template/inline function bodies inside the precompiled object files as extra info that the compiler loads in order to be able to expand templates/inline functions, compute the size of structs/classes (because private members are not listed in the API file), and so on. How this is feasible to implement, I can't say; some platforms may not allow arbitrary data inside object files, so the compiler may not be able to store the requisite information in them. [...] Not a bad idea, it's similar in function to .NET's Metadata. unfortunately to be useful, other linkers would have to be taught how to read that data... [...] That depends on how you do it. If we assume, for argument's sake, that we are allowed to store arbitrary data inside an object file (say inside a debug section or something), then the compiler could for example store things like parsed function bodies, partial syntax trees, etc., that allows it to treat templates and inline functions as though they actually were embedded in the interface file. When asked to compile a source file that imports the library, the compiler would read the object file, extract this info and use it to do whatever it needs to do (expand templates, inline functions, emit non-inlined function bodies, etc.). The generated object file can then be linked by the system's usual linker, assuming that the extra info in the library's object file is marked such that the linker simply ignores it. The linker doesn't have to know anything about it because the compiler has already done whatever needs to be done with it when it compiled the source file that imported the library. In fact, if a particular platform doesn't support such extra data inside object files, the compiler can simply save the data in its own internal format in another file, and the library writer just ships this file along with the human-readable API file and any precompiled library object files. As long as the customer's compiler knows to look for this file when compiling source that imports the library, it will have enough info to do what it needs to do. T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
Re: Struct initialization, implicit conversions and delegates
StringHash sh = SomeString; // ok That's the only thing that works. An @implicit tag for constructors to allow all implicit conversions would really be helpful. In general we need finer control of implicit conversions. Just have a look at ProxyOf: https://github.com/D-Programming-Language/phobos/pull/300/files#L0R2670 That's madness, all of that code just for getting alias this without implicit conversion to the original type.
Re: OOP Windows
On Mon, Jan 16, 2012, at 05:59 PM, Andrej Mitrovic wrote: On 1/16/12, Robert Clipsham rob...@octarineparrot.com wrote: https://github.com/AndrejMitrovic/DWinProgramming I think he's looking for an OOP approach, that code is basically C translated to D. There are some OOP libraries he can use, like DGUI or DFL. And there are some OOP wrappers for WinAPI somewhere (probably on dsource). Maybe http://pr.stewartsplace.org.uk/d/sdwf/ or http://www.dsource.org/projects/minwin. I think these two might be slightly outdated by now though. Yes. I know a bit of C (not C++) and the Windows API. Now I'd like to learn more about OOP. That's what I've found so far, both are for C++ programmers http://win32-framework.sourceforge.net/ http://relisoft.com/win32/ Wel..I'm not sure. Should I learn C++ before D? Thank you everybody.
Re: OOP Windows
On 01/16/2012 09:07 AM, Andrej Mitrovic wrote: Oh I thought that tutorial was about MFC/ATL, but it seems to use the regular C API. I might look into this to add it to the DWinProgramming project if it's worthwhile. I think it is worth a closer look. Especially Bartosz Milewski ActiveObject class. https://www.relisoft.com/win32/active.html OT @Andrej The MONO folks are using Cairo to rebuild MS NET System.Drawing and System.Drawing2D. I wonder if this could be an approach for DGUI. I quess my question is : using CAIRO or GDI+ as Graphic engine for DGUI. TIA Bjoern
Re: A tutorial on D templates
On Mon, Jan 16, 2012 at 17:36, Simen Kjærås simen.kja...@gmail.com wrote:
The extended enum example does not compile, because you've removed the
unittest{} block around the the tests. I'd say the code in your document
should compile straight out of the box, to be newb-friendly.
Yeah. I just coded a small D script that extract all code samples,
compile them and store the result in a log.
That way, I can now slowly make all samples compile.
I hesitate between showing the boilerplate or not (imports, empty
mains or code in main...)
As for an explanation:
This code generates an enum definition as a string, by taking all the
members of the old enum, and adding those passed in string parameter s,
and mixing it in.
Thanks! I'll add it.
Re: output minimal .di files?
On 01/16/2012 09:40 PM, H. S. Teoh wrote: On Mon, Jan 16, 2012 at 09:32:57PM +0100, Alex Rønne Petersen wrote: [...] I... don't think the error messages from expanding raw object code would be very pleasant to read, if you used a template incorrectly... [...] It doesn't have to be *executable* object code; the compiler may store extra info (perhaps as debugging data?) so that it can generate nicer error messages. But like I said, this assumes the compiler is allowed to store arbitrary data inside object files, which may not be the case on some platforms. T How would your proposal help hiding implementation details of templates anyway? All information still needs to be stored. Anyone could write a object file - source file compiler for template implementations.
Error: 'this' is only defined in non-static member functions, not parse
Hey everyone,
I, once again, have a problem with an error I can't seem to figure out!
The situation:
- a class, inherited by five other classes;
- the class having a static function which returns one
if its subclasses depending on the input of a string.
Something like this:
class Node
{
static Node parse(ref string s)
{
/* Get value to switch by, an enum. */
auto switchable = /* ... */;
final switch (switchable)
{
case Blah.one: return new OneNode(s);
case Blah.two: return new TwoNode(s);
/* ... */
}
}
}
And I get the mentioned error. I don't understand it:
is it saying I'm using `this' in a static member function
called `parse'? Am I insane; where am I referencing it?
The other classes are in this form:
class OneNode : Node
{
/* ... stuff ... */
this(ref string s)
{
/* Does stuff with `s'. */
}
}
Do you need more information?
Thank you,
Matej
Re: OOP Windows
On 1/16/12, bls bizp...@orange.fr wrote: I quess my question is : using CAIRO or GDI+ as Graphic engine for DGUI. Does DGUI intend to become cross-platform at any time? If not, then you could pick whichever system you're used to the most. You wouldn't be limited to just GDI+ if that's what DGUI will use, all you need for Cairo is a backbuffer to draw to which you can later blit to some widget area of DGUI.
Re: output minimal .di files?
On Tue, Jan 17, 2012 at 12:17:18AM +0100, Timon Gehr wrote: On 01/16/2012 09:40 PM, H. S. Teoh wrote: On Mon, Jan 16, 2012 at 09:32:57PM +0100, Alex Rønne Petersen wrote: [...] I... don't think the error messages from expanding raw object code would be very pleasant to read, if you used a template incorrectly... [...] It doesn't have to be *executable* object code; the compiler may store extra info (perhaps as debugging data?) so that it can generate nicer error messages. But like I said, this assumes the compiler is allowed to store arbitrary data inside object files, which may not be the case on some platforms. T How would your proposal help hiding implementation details of templates anyway? All information still needs to be stored. Anyone could write a object file - source file compiler for template implementations. It depends on what you understand by hiding implementation details. I see it from the point of view of encapsulation taken to its logical conclusion: users of the library only need to know the API of the library and nothing else. When they read the interface file, it should only contain the API and no implementation at all. In this sense, implementation details are completely hidden -- that's what encapsulation is all about. Of course, the *compiler* (and/or linker) obviously needs to know the full implementation details, otherwise it couldn't possibly produce the final executable. So this information has to come from somewhere, object files, compiler internal representation files, what-have-you. I don't think it's possible, even in theory, to prevent reverse-engineering of these sources of compiler information. Given enough determination, *anything* can be reverse engineered. And neither is prevention of reverse engineering the point. The point is that these are sources of *compiler* information, rather than information for library users. In that sense it's useful to separate information meant for the compiler, and information meant for users of the library. T -- All problems are easy in retrospect.
Re: Error: 'this' is only defined in non-static member functions, not parse
On 01/17/2012 12:49 AM, Matej Nanut wrote:
Hey everyone,
I, once again, have a problem with an error I can't seem to figure out!
The situation:
- a class, inherited by five other classes;
- the class having a static function which returns one
if its subclasses depending on the input of a string.
Something like this:
class Node
{
static Node parse(ref string s)
{
/* Get value to switch by, an enum. */
auto switchable = /* ... */;
final switch (switchable)
{
case Blah.one: return new OneNode(s);
case Blah.two: return new TwoNode(s);
/* ... */
}
}
}
And I get the mentioned error. I don't understand it:
is it saying I'm using `this' in a static member function
called `parse'? Am I insane; where am I referencing it?
The other classes are in this form:
class OneNode : Node
{
/* ... stuff ... */
this(ref string s)
{
/* Does stuff with `s'. */
}
}
Do you need more information?
Yes; It is extremely hard to solve the problem when there is no code
snippet given which exhibits the problematic behavior in question.
Re: OOP Windows
On Monday, 16 January 2012 at 21:52:09 UTC, DNewbie wrote: Yes. I know a bit of C (not C++) and the Windows API. Now I'd like to learn more about OOP. I'm not really sure if that is the best strategy for learning OOP, even in C++. Though I guess it could give the before an after effect of an API. But going with C++ you'd just be learning a lot about C++ and that overhead would mask the learning about OOP. D doesn't really have tutorials on OOP, that I know of. There are some examples about class and objects, but no true OOP tutorials (actually these are hard to find). If you want to do some GUI with OOP then DFL isn't bad, documentation and tutorial are exactly complete, but it might give you some thing to work with. And the Entice designer can help build some code for you to look at (I've used it to find what classes I need and their options :P) http://www.dprogramming.com/dfl.php
Meaning of pure member function
The following code compiles without error:
class C {
int x;
// what does 'pure void' mean??
pure void f() {
x++;// why is this legal?
}
}
What does 'pure' mean when applied to a member function? Based on
Andrei's book, 'pure' means that the function's result depends only on
its input. And based on the fact this code compiles, I deduced that
'this' is included as part of the function's input.
However, the function is clearly changing one of its inputs (changing a
member of 'this'). Furthermore, what on earth is 'pure void' supposed to
mean and why does the compiler accept it?
Changing the function to read:
pure int f() { return x++; }
also compiles without any complaint from the compiler. Yet calling
writeln() from within f() produces an error. Why?
T
--
Computerese Irregular Verb Conjugation: I have preferences. You have
biases. He/She has prejudices. -- Gene Wirchenko
Re: Meaning of pure member function
On Tuesday, 17 January 2012 at 05:16:33 UTC, H. S. Teoh wrote:
The following code compiles without error:
class C {
int x;
// what does 'pure void' mean??
pure void f() {
x++;// why is this legal?
}
}
What does 'pure' mean when applied to a member function?
This is a weakly pure function usable by strongly pure functions.
Namely it is a helper function to those that can claim to be
strongly pure.
Maybe bearophile's blog will shed some light:
http://leonardo-m.livejournal.com/99194.html
Or stackoverflow:
http://stackoverflow.com/questions/5812186/pure-functional-programming-in-d
Furthermore, what on earth is 'pure void' supposed to
mean and why does the compiler accept it?
Well it can only be useful as a weakly pure function as those are
allowed to modify their arguments.
In any case, if the function was strongly pure:
pure void foo() {}
any call to it would just be eliminated as having no side effects.
