== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s
article
> On Mon, Mar 16, 2009 at 1:50 PM, Nicholas Jordan <a...@some.com>
wrote:
> > I put some fields at the front of my first attempt as a note while
> > prototyping, the compiler did not accept the syntax from the
sample
> > code. I had to do it like this:
> >
> > invariant {long fail__= -123456;}
> >
> > with the brackets surrounding, for this question - what I want
here is
> > several values that are never changeable and always represent some
> > sort of status return from calls - always the same. The above code
is
> > not compliant with the code shown in the discussion of what D is
all
> > about.
> The problem is that this conflicts with the D1 syntax for
class/struct
> invariants. This is probably why the immutable keyword has been
> introduced, and I have a feeling invariant as a form of constness
will
> be renamed immutable.
> Just use:
> immutable
> {
> long foo = 4;
> int bar = 12;
> }
> But you said that these are return statuses? Why not use enums
instead?
ran htod.exe on jni.h - this looks sane to me. Some concepting issues
but is a step forward in computer science, so what I do is just list
that file on the command line to C:\dmd\bin\dmd.exe along with what it
produces on EZ-Twain dot h along with other things I might write that
would make more sense to me as a file scope code base, the compiler
de-facto takes file scope into account?
In other words, in file foo.d I have a function, on which I want to
feed it a bar from compilation unit recognition - this is sorta
obvious for a compiler writer, seems to me to even throw some cs
301's, but redeclaration in each file scope would lead to the same
issues we are trying to parallelize.
I have a rich skill base in subtle nuances of parallelizing work, this
is the time to fix this. If it gets broken later, one may need your
burger-flippin resume' to be ready to deliver.
