Why doesn't SuperStrict throw an error if...

BlitzMax Forums/BlitzMax Programming/Why doesn't SuperStrict throw an error if...

plash

(Posted 2008) [#1]

...a function, that has a return type, does not return something?

SuperStrict

Framework brl.standardio

Local something:Object = IReturnSomething()

Function IReturnSomething:Object()
	
	Print "OHai!"
	
End Function

ImaginaryHuman

(Posted 2008) [#2]

It'll return Null?

degac

(Posted 2008) [#3]

Maybe because in your example nothing is returned.
Or it's handled automatically by bmax

big10p

(Posted 2008) [#4]

I'm new to blitzmax but that does seem odd to me for SuperStrict Plash, yes.

plash

(Posted 2008) [#5]

It'll return Null?

It has a return type, and should throw an error because I am not returning a value - imo.

Maybe because in your example nothing is returned.

That's the point, it should throw an error.. :(

Or it's handled automatically by bmax

I wish it weren't. SuperStrict is for avoiding typo's/error's, the function should have to return something in code, not by default.

I'm new to blitzmax but that does seem odd to me for SuperStrict Plash, yes.

*	(Posted 2008) [#6]

Basically its down to you to check something is loaded into the object, this is the same for ALL loading commands its down to you to check its loaded. If nothing can be loaded it returns Null as default, just check to make sure your value isnt null and you will be ok.

I prefer BlitzMax SuperStrict to stick to the way it is as checking for null is a lot easier than checking through for loads of errors because I didnt return a value, its not C where 'function should return a value' warnings crop up everywhere.

plash

(Posted 2008) [#7]

its not C where 'function should return a value' warnings crop up everywhere

Right, but functions that have a return type should be returning something. If you want to check if a function returned Null it can cause issues if has done that by default and the developer forgot to return the correct value (in this case Null).

I suppose its just opinion.. SuperStrict should be truly super strict!

big10p

(Posted 2008) [#8]

its not C where 'function should return a value' warnings crop up everywhere.

Unfortunately. C doesn't do that simply to be a pain in the arse, it does it to try and point out to the coder that they've made a mistake.

Grey Alien

(Posted 2008) [#9]

I would find typing Return 0 (this is what BMax does) at the end of every function as hassle.

SpaceAce

(Posted 2008) [#10]

I think Plash has a good point, here. Not that I think failing to return a value is really a huge problem for most of us, but when you ask for "SuperStrict," you should get super strictness.

Saying that you don't want errors cropping up or you don't want to have to add return statements to your functions is the same as saying, "I want to be sloppy." So, why are you using SuperStrict?

SpaceAce

plash

(Posted 2008) [#11]

I would find typing Return 0 (this is what BMax does) at the end of every function as hassle.

That's not what I'm saying. I'm saying that, in SuperStrict, you should have to return a value for every function/method that has a return type.

So for:

Function SomethingOrAnother()
	Print "I don't have to return jazz"
End Function

I wouldn't have to return a value, especially since you can't actually return a value from that function.

Saying that you don't want errors cropping up or you don't want to have to add return statements to your functions is the same as saying, "I want to be sloppy." So, why are you using SuperStrict?

This is why I protest the modules being Strict and not SuperStrict.. But since it currently doesn't MAKE YOU return a value from a function/method that HAS a return type it wouldn't help.

This is an example of one of the recent errors due to the standard modules being Strict and not SuperStrict (if it were actually SUPER strict).

grable

(Posted 2008) [#12]

How about some DoublySuperStrict for the masochists? Dont mess with my SuperStrict, i likes it the way it is!

ziggy

(Posted 2008) [#13]

This could be a good example for a compiler warning. But Max doesn't produce compiler warnings, so...

Grey Alien

(Posted 2008) [#14]

That's not what I'm saying. I'm saying that, in SuperStrict, you should have to return a value for every function/method that has a return type.

OK got it. I see what you mean.

Perturbatio

(Posted 2008) [#15]

could there be a situation where you would want to not return anything sometimes?

A brief but not directly useful example:

SuperStrict

Const itemLimit:Int = 10

Type TItem
	Field id:Int
	
	Global lastId:Int = 0
	Global list:TList
	
	Const itemLimit:Int = 10
	
	Function Create:TItem()
		If Not list Then list = New TList
		
		If list.count() < itemLimit Then 
			Local tempItem:TItem = New TItem
				lastId:+1
				tempItem.id = lastId
				
				list.addLast(tempItem)
			Return tempItem
		EndIf
	End Function
	
End Type


For Local i:Int = 0 To 10
	Local item:TItem = TItem.Create()
	If item Print item.id
Next

ziggy

(Posted 2008) [#16]

Yes, in this case a Return Null would be enough :D

marksibly

(Posted 2008) [#17]

Hi,

I think it should be an error...but would it break much SuperStrict code if 'fixed'?

plash

(Posted 2008) [#18]

So.. maybe add SuperDuperStrict? :)

EDIT:
@Perturbatio: So how do you plan on informing the developer that the item could not be added? By returning Null, which is what it does by default - if it didn't you would just have to be certain you told the developer that the object wasn't created (the better way, in my opinion).

Retimer

(Posted 2008) [#19]

What about a superstrict that can hold optional arguments that can alter the default options?

SuperStrict(<optional values>)

Kurator

(Posted 2008) [#20]

Mark,

warnings would be more cool and will not break any existing code.

No strict statement: No warnings, no typechecking
Strict: No warnings, but typechecking
SuperStrict: All warnings, and restrictive typechecking

maybe we could find some useful compilerwarnings except those "missing return value", like if/then complete checking ect.

plash

(Posted 2008) [#21]

warnings would be more cool and will not break any existing code.

I agree, and this way the warnings could just be added to the current SuperStrict - functions/methods should still return null by default.

ziggy

(Posted 2008) [#22]

I also agree. I think proper warning are always welcome on a great compiler such as the blitzmax one.

SpaceAce

(Posted 2008) [#23]

Is there really much danger of breaking code by making this an error? It seems to me that the worst case scenario involves going through your code and add a few returns. You'd only have to fix paths that led to no return value.

SpaceAce

H&K	(Posted 2008) [#24]

OK, Havent read it all, no time nowadays too buzy

I dont mind either way about this, BUT PLEASE dont make superscript throw an error if the Function Does return an object which isnt then allocated to anything

Yep I know this thread isnt about this. BUT as MArk has asked, thought Id just make sure

Gabriel

(Posted 2008) [#25]

I agree with SpaceAce. I've got a huge amount of existing BlitzMax code, and I'm sure I have a fair few functions which can return something but do not always do so. However, fixing that is a simple job, and would take very little time. You shouldn't hold back from changing something relatively important for such a trivial reason as me having to add a few Return's.

plash

(Posted 2008) [#26]

BUT PLEASE dont make superscript throw an error if the Function Does return an object which isnt then allocated to anything

I don't think that's how it would work. You should still be able to return an uninitialized object from the function (it will just be returning Null, since the object hasn't been set - or 'initialized') without an error, the change should just be checking for the return call.