First of all, let me just say you did a fantastic job on the write-up of this concept! It's really insightful, crystal clear, and shows the amount of research you've done!

Of the two suggested implementations, I agree the second one looks less boilerplate to use overall. However using both ok and Ok for two different things could be very confusing, as they have different return values. But, maybe you could get away with using the same type twice?

Result!(int,string) div(int a, int b)
{
	if (b == 0) return err!string("Cannot divide by 0!");
	else return ok!int(a/b);
}

From what I've understood, the type you use for the templates ok and err is not used, and in theory can be anything; if that is correct, I'd say it might as well be the type of the thing that's coming afterwards. This would make code less confusing to both read and write, but the problem doesn't truly go away either. But I'm assuming there's no way to implement this feature without a compromise anyways.

Also I agree with most proposed utility functions to handle Results, although I'm not seeing the usefulness of some:

• expect and unwrap look to do the same thing; halt program execution if Result is an Err, with expect accepting a message to present, ala assert style. But in that case, I don't see why a simple assert("This should work", r.unwrap()); wouldn't be enough for this.
• What is the purpose of flaten? Even if I have nested Results, I'm only interested in the final, top-level Result; wouldn't using all the other functions (isOK(), isErr(), has(), etc...) already provide the same value? (in other words, isn't result.flaten.isOK() == result.isOK() always true?)

However using both ok and Ok for two different things could be very confusing, as they have different return values.

Ok is the type itself. This type is not supposed to be used outside Result unless it's used for instantiating one or for comparison. The helper ok says that it returns an Ok Result. While the Result type is one of Ok or Err not the same applies to Ok. A Result may be an Ok, however an Ok is not a Result. So ok is directed to Ok but not directly. Using ok is the same as doing:

...
return immutable(Result!(<typeA>,<typeB>)(Ok!(typeA)));

I'd say it might as well be the type of the thing that's coming afterwards.

But it is, your example is wrong. The type specified is the opposing type. Also I may not have presented every usage of the template functions.

Result!(int,string) fc1(...)
{
	if (...) return ok!string(...); // must specify ErrT --> string;
	else return err!int(...) // must specify the OkT --> int
}

// same as Result!()
Result!(void,void) fc2(...)
{
	if (...) return ok(...); // no need to specify as void is default
	else return err(...) // ditto
}

expect and unwrap look to do the same thing; halt program execution if Result is an Err, with expect accepting a message to present, ala assert style. But in that case, I don't see why a simple assert("This should work", r.unwrap()); wouldn't be enough for this.

Yes. But that's not usefulness of these functions. Both unwrap and expect assert if the Result is Err with the difference that unwrap asserts with Err's value and expect assert with a message following the Err's value. The useful feature is that both return OkT. This make chaining simpler as well as making the code cleaner. Other thing is that asserting or throwing shouldn't be the purposed of this, the objective is to avoid such endings. Look at this case for example:

auto strnum = ["12","23","1","45","6"];

// lets suppose parse function returns Result
auto val = strnum
	.map!(str => str.parse!int)
	.map!(resut => result.unwrap())
	.fold!"a+b";

Well this is pretty neat! With a simple function we parsed, mapped and summed all numbers! However this would assert if parse went wrong! To overcome this we would have functions like unwrapOr and unwrapOrDefault which would take an OkT value and return it if Result was Err. Yes I did not mention such functions.

auto strnum = ["12","invalidnumer","1","45","6"];

// lets suppose parse function returns Result
auto val = strnum
	.map!(str => str.parse!int)
	.map!(resut => result.unwrapOrDefault())
	.fold!"a+b";

In case you didn't want to use replacement values for failed Results the you could filter them as well.

auto strnum = ["12","invalidnumer","1","45","6"];

// lets suppose parse function returns Result
auto val = strnum
	.map!(str => str.parse!int)
	.filter!(result => result.isOk())
	.map!(resut => result.unwrap())
	.fold!"a+b";

The other useful aspects using only the functions:

auto a = somefuncwhichmayfail.unwrap(); // a = OkT or asserts
auto b = somefuncwhichmayfail.expect("oops"); // a = OkT or asserts with an extra message

What is the purpose of flaten? Even if I have nested Results, I'm only interested in the final, top-level Result; wouldn't using all the other functions (isOK(), isErr(), has(), etc...) already provide the same value? (in other words, isn't result.flaten.isOK() == result.isOK() always true?)

No, not all functions would return the same. Although isOk and isErr would return the same output, functions like has, unwrap, expect, etc, would not.

auto res = ok(ok(3)); // is of type Result!(Result!(int,void),void))

assert(!res.has(3)); // not true because `OkT == Result!(int,void)`
assert( res.has(ok(3))); // true
assert( res.has(Result!(int,void)(Ok!int(3))); // same as above

assert(res.flatten.has(3)); // now it's true as `OkT == int`

assert(ok(ok(3)) == res);
assert(ok(3) == res.flatten());
assert(ok(3) == res.flatten.flatten()); // when it's reduced to an atomic level it returns the same

I'm against some things on this proposal, but overall I guess this should be the way to go.

The implementation of some projection structs and the final proposed helper functions can lead to some confusion:

auto ok(ErrT=void,OkT)(OkT value) { return immutable(Result!(OkT,ErrT))(Ok!OkT(value)); }
auto ok(OkT=void,ErrT)(ErrT value) { return immutable(Result!(OkT,ErrT))(Err!ErrT(value)); }

Maybe you wanted the second one to be err(...) right? Anyway, my point is not the naming, and it's rather the template arguments. You can simply use T as a type on the function template.

Should be, instead:

auto ok(T)(T value) { return Result!(T,void))(Ok!T(value); }
auto err(T)(T value) { return Result!(void,T))(Err!T(value); }

Another thing I'm against this implementation is the enforcement of the immutable qualifier on Result state and on the return value of the helper functions.

We shouldn't enforce the usage of immutable storage. The user should choose the qualifiers for its own data.

Another point I want to touch on that we should be aware of is: The user could choose to use a non-copyable struct. See the implementation taken from Optional type:

public auto some(T)(auto ref T value)
{
	import std.traits : isCopyable;

	static if (!isCopyable!T)
	{
		import std.functional : forward;

		return optional!T(forward!value);
	}
	else
	{
		return optional!T(value);
	}
}

I would say that getters are not "Future additional content". In this case, getters are mandatory to get the Result projections and there's no other way to directly get them.
We could also have two versions of getters. getOk returns an optional, but if the user gives a default by using the same name or a more descriptive name like getOkOr(value) we could get T instead of Optional!T.

Some final thoughts:

• We could name the payload union to do something like payload.ok instead of okpayload.

Maybe you wanted the second one to be err(...) right? Anyway, my point is not the naming, and it's rather the template arguments. You can simply use T as a type on the function template.
Should be, instead:
auto ok(T)(T value) { return Result!(T,void))(Ok!T(value); }
auto err(T)(T value) { return Result!(void,T))(Err!T(value); }

Yes the second function in the first example is wrong, should be err. Your suggestion, as explained above, does not work. You're returning a different type from the function's ReturnType.

Result!(int,string) div(int a, int b)
{
	if (b == 0) return err("Cannot divide by 0!"); // Cannot implicitly convert type Result!(void,string) to Result!(int,string)
	else return ok(a/b); // Cannot implicitly convert type Result!(int,void) to Result!(int,string)
}

It might not be ideal but we no other choice. Both types must be specified and only one of them can be inferred by D. Maybe if noreturn gets accepted we can improve this, but right now there isn't any other choice.

Another thing I'm against this implementation is the enforcement of the immutable qualifier on Result state and on the return value of the helper functions.
We shouldn't enforce the usage of immutable storage. The user should choose the qualifiers for its own data.

The State doesn't have anything to do with the payload. Once a Result is established, then it stays like that. The objective of this feature is to be used as a ReturnValue not anything else. I'm only enforcing immutability on the Result itself, not it's content. If you want to change to content, either you construct a new Result with the new value, or you extract it from Result to a new variable and work that way. Result should only hold something and not have the ability to let the user manipulate its contents. You should never be able to have an Ok Result and then assign an Err to it! Once again if something like that happens just construct another Result. Some functions to construct another Result are in my mind.

• map which would transform Result(T,ErrT) --> Result(U,ErrT)

auto strnum = "12";

// imagine parse!int returns Result!(int,string)
auto res = strnum.parse!int.map!(i => to!string(i*2)); // takes an `Ok`'s value and maps it

// res --> Result!(string,string)(Ok!string("24"));
assert(Ok!string("24") == res);

• mapError
• mapOr
• mapOrElse

These are future functions which will enhance Result but can't be implemented at the moment. And since you brought up Optional (which isn't a valid proposal, I'll get there), let me follow the same route and show an example with match.

auto strnum = ["1","invalid","3","4"];

foreach (str; strnum)
{
	str.parse!int.map!"i*2".match!(
		(Ok!int ok) => ok.writeln();
		(Err!string err) => err.writeln();
	);
}

/* prints:
2
<Some parse error message>
6
8
*/

Another point I want to touch on that we should be aware of is: The user could choose to use a non-copyable struct. See the implementation taken from Optional type:

Once again we can have Result immutability with this.

I would say that getters are not "Future additional content". In this case, getters are mandatory to get the Result projections and there's no other way to directly get them.
We could also have two versions of getters. getOk returns an optional, but if the user gives a default by using the same name or a more descriptive name like getOkOr(value) we could get T instead of Optional!T.

Yes they are. Optional is a concept which would be introduced in Taurus but right now, it isn't implement, that for, we cannot enforce it as a dependency. Optional is another theme/feature, and this one should function 100% independently from it. The Additional functions have options to get such values, unwrap, expect, and as mentioned above we could implement unwrapOr and unwrapOrDefault. So if you want to get OkT from an Ok Result safely then you would do:

if (res.isOk()) someval = res.unwrap();

Right now we don't have manners to filter or map or pull any fancy ways to get the value. It has to be this way. Optional conversation is valid when it's implementation arrives. But you can't decide what is mandatory with non existent dependencies at the moment.

But it is, your example is wrong. The type specified is the opposing type. Also I may not have presented every usage of the template functions.

Yes, I assumed that the type you specify after ok/err could be anything, but from the example you posted above, I now realize it's not possible:

Result!(int,string) div(int a, int b)
{
	if (b == 0) return err("Cannot divide by 0!"); // Cannot implicitly convert type Result!(void,string) to Result!(int,string)
	else return ok(a/b); // Cannot implicitly convert type Result!(int,void) to Result!(int,string)
}

The only thing that worries me about this constraint is the confusion it may cause to people outside the framework that wish to develop on it (I assume, from your examples above, that if someone is just using your framework, they will instead work with Ok/Err types to compare any Results).

Also I noticed that the type for the error is a string in all your examples; do you wish to enforce this, or would the user be able to use another type if he wishes to? Because if you intend for it to always be a string, you could probably simplify the definition of Result and implicitly solve this issue.

But yeah, this is my only gripe with the implementation, simply because it has the potential to be confusing. I understand this is a constraint from the language itself and there's not much it can be done though, so I'll leave it to that.

The only thing that worries me about this constraint is the confusion it may cause to people outside the framework that wish to develop on it (I assume, from your examples above, that if someone is just using your framework, they will instead work with Ok/Err types to compare any Results).

I agree with this. Internally we should try to specify almost all the ReturnTypes so it's much easier to understand the output. If we say what type the function returns Result(X,Y) then with some basic and raw assumptions it's much more easier to figure out what each ok and err do even if not familiar with the lib or the concept. But once again lets hope noreturn gets accepted quickly and its usage applies to this case.

Also I noticed that the type for the error is a string in all your examples; do you wish to enforce this, or would the user be able to use another type if he wishes to? Because if you intend for it to always be a string, you could probably simplify the definition of Result and implicitly solve this issue.

I used string, but it's not mandatory. Any type will do. I opted for this because it's easier to understand the concept, and it will be a common error type. Others are void, enum. Each module will have a set of errors grouped in an enum and that will be the most used type internally. Instead of exception hierarchies or singled out exceptions we would replace it with enums.

@ljmf00 @ev1lbl0w updated proposal.