nlupugla

I looked through Godot's API to find methods where a Dictionary is currently used and a Struct might be more approprate. I found about 130 methods accross the codebase. My approach wasn't terribly systematic: I used ctrl-f to search extension_api.json for "type": "Dictionary" and "type": "typedarray::Dictionary". I removed some methods from the list where a Dictionary really did seem appropraite. That said, there are probably still several "false positives" in this list. I don't intend to modify all of these on my own. Rather, I'll start by structifying a handful of the most commonly used methods and leave it to others to structify the rest as the need/demand arrises.

ClassDB::class_get_signal_list()
ClassDB::class_get_property_list()
ClassDB::class_get_method_list()
CodeEdit::_filter_code_completion_candidates()
CodeEdit::get_code_completion_options()
DisplayServer::tts_get_voices()
EditorExportPlugin::_get_export_options()
EditorImportPlugin::_get_import_options()

Type Theory

Type theory is the mathematical and computational study of type systems, like the ones you use in popular programming languages. It can get very abstract, but I believe it offers some useful concepts to take home even for practical language design. In particular, I am interested in contributing to the Godot game engine's scripting language GDScript https://github.com/godotengine/godot/tree/master/modules/gdscript, so I will try to relate the abstract concepts to concrete examples in GDScript where possible.

The following are some notes I've compiled through some self-study that mostly includes skimming Types and Programming Languages by Benjamin C. Pierce https://github.com/MPRI/M2-4-2/blob/master/Types%20and%20Programming%20Languages.pdf, browsing various Wikipedia articles,

	#define GDSTRUCT(m_struct) \
	private: \
	friend class ::ClassDB; \
	\
	public: \
	typedef m_struct self_type; \
	static constexpr bool _class_is_enabled = !bool(GD_IS_DEFINED(ClassDB_Disable_##m_struct)); \
	virtual String get_class() const override { \
	return String(#m_struct); \
	}

	//// Under the current proposal, the workflow for exposing a struct would look like the following (using PropertyInfo as an example).

	/// In Object.h, where PropertyInfo is defined

	// Forward declare Struct template
	template <typename T>
	class Struct;

	/// In Object.cpp

	/* This gist details a way of representing type data in C++ that I have found useful for implementing structs.
	* Rather than represent type data as local variables on an instance of some kind of TypeInfo struct,
	* I represent each type via static methods on a corresponding metatype. Representing the data as metatypes
	* allows the compiler to understand what our types mean and enables some cool template metaprogramming tricks.
	* defined at compile time, which allows for many cool template metaprogramming tricks. */

	/* Here is an example of a struct whose members have been defined via metatypes. */

	struct NamedInt {
	StringName name = StringName();