Safety, undefined behavior, @safe, @trusted

[Sclytrack]

== Quote from Knud Soerensen (4tuu4k002 at sneakemail.com)'s article
> Instead of just defining @safe and @trusted
> it should possible to define this type of code annotations and
> constrains in D.
> See Red Code/Green Code - Generalizing Const by Scott Meyers
> http://video.google.com/videoplay?docid=-4728145737208991310#
> Then we can define @safe, @pure, @thread_safe, @exception_safe, @gpl,
> @lgpl, @beautiful and @ugly code or all the constrains we like.
> It would also be nice if we could annotate code with @debug
> and then it would argument the code with debugging code.
> Walter Bright wrote:
> > Following the safe D discussions, I've had a bit of a change of mind.
> > Time for a new strawman.

I'll watch that video tomorrow, (or not it is a bit long.) :-)


attrib(nogc)
void handleSituation1()
{
	int * m =casting malloc(20);
}

attrib(nogc)
void handleSituation1() requires(nogc)
{
	handleSituation2();
}

void helloWorld()
{
	requires(nogc)
	{
		handleSituation2();
	}
}

attrib(validatedBy("Tom hank"))
void doStuff3() requires(validatedBy)
{
	callThis();
	callThat();
}

attrib(trusted) void handleSituation() requires(nogc) permit(unsafe)
{
}

void handleSituation() permit(unsafe)
{

}

void handleSituation()
{
	...
	permit(unsafe)
	{

	}
}

----mutable isolation = mutiso

requires(pure)
class BoeClass
{
private:
	int number;
public:
	prop int Number
	{
		return number;
	}
	{
		number = value;
	}

	int dupsy()
	{
		return number + 1;
	}
}


requires(pure) int doStuff( int a)
{
	BoeClass jim;
}




--------

void doStuff()					//attrib(safe) requires(safe)
attrib(safe) void doStuff() requires(safe)	//default
void doStuff() permit(!safe)			//loses the safe attribute
requires(safe) void doStuff()			//enforces and attributes it.
requires(nogc) void doStuff()			//enforces and attributes it.
void doStuff() requires(nogc)			//enforces but does not attribute it.
attrib(validated) doStuff() permit(!safe)	//validated by the programmer using
unsafe code


attrib(default) void doStuff() requires( default - [safe] )


Okay I'm going nuts again.

-----------------


Okay for let's say "properties" that are meant to be serialized. By which I mean
"actual data", could we start them with a capital case. This would tell other
programmers which ones to pick. Bad idea?


struct Area
{
	int Width()			//Big letters
	{
		return width;
	}
	int Height()			//Big letters
	{
		return height;
	}
	int area()			//small letters
	{
		return width * height;
	}
}