Walter wrote:
> "Charles Hixson" <charleshixsn@earthlink.net> wrote in message
> 
>>How do you see run-time contract violations as being handled?
>>The possibilities that occur to me are program termination (Ouch!) and
>>exceptions (or Eiffel's Resume blocks).
>>
> 
> As throwing an exception.
> 
...
> 
Sorry.  I had misunderstood that the exception mechanism was being removed.

Good catch! Thanks.

Russ Lewis wrote in message <3B8559AD.8EE411E1@deming-os.org>...
>I was reading the pages you put up.  Nice summary :)
>
>However, there is a serious discrepancy between http://www.digitalmars.com/d/lex.html and
http://www.digitalmars.com/d/ctod.html
>regarding escaped characters in strings.
>
>lex.html says that strings in double-quotes include escape characters like
C,
>while strings in single-quotes are taken as-is:
>
>"deltree c:\\windows\n"
>    is the same as
>'detree c:\windows' \n
>
>ctod.html says that strings in double-quotes cannot have escape characters.
>

Charles Hixson wrote in message <3B86743A.8010903@earthlink.net>...
>Walter wrote:
>> "Charles Hixson" <charleshixsn@earthlink.net> wrote in message
>>
>>>How do you see run-time contract violations as being handled?
>>>The possibilities that occur to me are program termination (Ouch!) and
>>>exceptions (or Eiffel's Resume blocks).
>>>
>>
>> As throwing an exception.
>Sorry.  I had misunderstood that the exception mechanism was being removed.


No prob. From the feedback in this group, I've been able to improve the spec a lot. There are a lot of errors and vaguenesses in it.

Walter wrote:
> 
> kaffiene wrote in message <9ltg04$2361$1@digitaldaemon.com>...
> >--- Multiple Return Values from Functions ---
> >psheer introduced the idea of multiple return types for functions.  We've discussed possible syntax and a lot of positive comment has been made.
> I've
> >suggested that it's a much better idea that in, out and inout variables. Walter, what do you think?
> 
> A large reservation I have is that the syntax is too different from C. Tuple returns will take a lot of getting used to. BTW, some of my colleagues have been very adamant about the advantages of multiple return types <g>.

	For what it's worth, it might help in making parts of the library less
dependent on each other.  You wouldn't have to deal with a web of
feature specific objects that must be supported through out the
library.  Given the 'safety first' nature of D in most cases, I doubt
that a library that made great use of multiple return values would be
accepted.  Also if you don't allow a function returning multiple value
to be used in the place of multiple arguments in another function, then
the gain wouldn't be much.  It's still a cool feature.  :-)

Dan

"David Caldlwell" <bogus@porkrind.org> wrote in message news:9lvdlb$603$1@digitaldaemon.com...
> My personal interests are:
>  - enum.stringrep property (returns the name of an enum as a string). I
> can't tell you how often I have to have parallel arrays just for debugging
> stupid enums. As Walter pointed out in the D spec, parallel arrays are
> annoying (ie, forgetting to change one of them and then everything is
> mismatched). And the beauty of the module system is that the strings never
> need to be compiled into the resulting code unless they are used. Perfect
> for debugging. Most of the ideas in the "super enums" thread were very
good.

Just have enums automatically have the ability to be converted to a string. Pascal did this from what I remember.  Any enums that aren't actually ever converted to strings, would not require the runtime to contain those strings.

>  - Some way to deal with hardware specific issues. little-endian and
> big-endian built in types could be very useful for reading rigid file
> formats using cross-platform code. Most non-x86 processors have
instructions
> for reading opposite-endian integers, so it doesn't even have to be
horribly
> inefficient. This could also be useful for talking to hardware.

I'd also like to see this built into the language somehow, but if it was a modifier tacked onto a basic integer/float type, it would be a big drain on performance to manipulate variables declared that way.  I'd only ever use endian specifications on structs representing disk data structures where I knew the file needed to be portable to multiple platforms.  For games, the overhead of conversion is usually not acceptable, so we end up having to make file converters for each platform.  The feature would help to write those kinds of tools, however.  ;)

Unfortunately I think endianness is such a platform specific thing that it's possible in the future someone will make a processor that uses some totally different scheme to arrange the layout of integers in memory.  The language should probably be platform agnostic.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9s2fbc$2264$1@digitaldaemon.com...
> Unfortunately I think endianness is such a platform specific thing that
it's
> possible in the future someone will make a processor that uses some
totally
> different scheme to arrange the layout of integers in memory.  The
language
> should probably be platform agnostic.

How I see resolving endian issues is via a class derived from OutBuffer and InBuffer, which respectively read and write to arrays of bytes. OutBufferLittleEndian, InBufferBigEndian, etc., translate to/from endians.

"Walter" <walter@digitalmars.com> wrote in message news:a1j6gt$2b02$2@digitaldaemon.com...

> How I see resolving endian issues is via a class derived from OutBuffer
and
> InBuffer, which respectively read and write to arrays of bytes.

OutBuffer AND InBuffer? D supports multiple inheritance???

> OutBufferLittleEndian, InBufferBigEndian, etc., translate to/from endians.

Um... why not just overloaded btol() and ltob()?