I have a service which syncs various data from LDAP into a database on a given interval. We sync roughly 50,000 users, and 48,000 groups from LDAP during this process, and it's a hit or miss on the standards for how these will show up. An example of one of the structs that's used as part of the Entry.Unmarshal() process:

type UserLDAP struct {
	ObjectGUID        string  `json:"object_guid"         ldap:"objectGUID"`
	CommonName        string  `json:"common_name"         ldap:"cn"`
	Description       *string `json:"description"         ldap:"description"`
	DisplayName       *string `json:"display_name"        ldap:"displayName"`
	DistinguishedName string  `json:"distinguished_name"  ldap:"distinguishedName"`
	Mail              *string `json:"mail"                ldap:"mail"`
	SAMAccountName    string  `json:"sam_account_name"    ldap:"sAMAccountName"`
	UserPrincipalName string  `json:"user_principal_name" ldap:"userPrincipalName"`
	ThumbnailPhoto    []byte  `json:"thumbnail_photo"     ldap:"thumbnailPhoto"`
}

The idea is that for the fields which aren't actually defined in the source object within LDAP/AD, those would be nillable within the struct, and I could easily determine if something is set, but an empty string, vs not set (for example).

However, with v3.4.6 today, this results in the following, which means we have to do checks against many fields to see if they are empty (and still can't tell if it was originally set or not):

ldap: expected field to be of type string, []string, int, int64, []byte, *DN, []*DN or time.Time, got *string

Would it be possible to support nillable fields, or is there some lower level protocol issue with doing this?